Link performance prediction technologies

ABSTRACT

The present disclosure is related to Link Performance Predictions (LPPs), which are used in connection with management of radio communication links. The LPPs are predictions of future network behaviors/metrics (e.g., bandwidth, latency, capacity, coverage holes, and/or the like). The LPPs are communicated to network nodes, which allows the network nodes to make operational decisions for improved signaling/link resource utilization. The link performance analysis is divided into multiple layers that determine their own link performance metrics, which are then fused together to make an LPP. Each layer runs different algorithms and/or machine learning models, and provides respective results to an LPP layer/engine that fuses the results together to obtain the LPP. Other embodiments are described and/or claimed.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.17/505,919 filed on Oct. 20, 2021 (“'919”), which is a divisional ofU.S. application Ser. No. 16/452,352 filed on Jun. 25, 2019 (“'352”),the contents of each of which are hereby incorporated by reference intheir entireties and for all purposes.

TECHNICAL FIELD

The present disclosure is generally related to data processing, networkcommunication, and communication system implementations, and inparticular, to techniques for determining and utilizing link performancepredictions (LPPs) and/or link quality predictions (LQPs).

BACKGROUND

Emerging wireless network technologies (e.g., Fifth Generation (5G) orNew Radio (NR)) are expected to provide increased improvements in datarates, device density, latency, and power consumption. Some new servicesthat may exploit these improvements include gigabit wireless broadbandnetwork access, smart factories, rich media content streaming includingvirtual and augmented reality gaming, autonomous or semi-autonomousdriving applications, services provided by unmanned aerial vehicles(UAVs), and cloud computing and/or edge intelligence services. To makethe most of these potential improvements, mobile network operators willneed to transition from a single purpose consumer broadband network to aversatile network supporting services as diverse as high-density sensornetworks to real-time safety and mission-critical industrialapplications.

The realized and perceived performance of wireless networks depends onradio link quality. The variation in wireless network performancebecomes more pronounced as link quality conditions are more dynamic,such as when user equipment are highly mobile (as opposed to beingrelatively static). As a result, the realized and/or perceivedperformance of wireless networks will be dependent on the conditionsexperienced on the wireless link.

Currently, some network traffic types (e.g., streaming media) aretolerant to some delay, within buffering limits, while other types oftraffic (e.g., bulk software downloads) are even less sensitive todynamic link quality conditions. Building additional infrastructureand/or using reactive solutions (e.g., Dynamic Adaptive Streaming overHypertext Transfer Protocol (HTTP) (DASH or MPEG-DASH) and HTTP LiveStreaming (HLS)) to address variations in network conditions (e.g.,performance and congestion) has often been enough to provide sufficientquality of service and/or quality of experience for these traffic types.However, these existing solutions may not be sufficient to support newtraffic types and/or new services that may be realized by the emergingwireless network technologies.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numeralsmay describe similar components in different views. Like numerals havingdifferent letter suffixes may represent different instances of similarcomponents. Some embodiments are illustrated by way of example, and notlimitation, in the figures of the accompanying drawings in which:

FIG. 1 depicts an example edge computing environment;

FIG. 2 illustrates example logical components and interaction points ofLink Performance Prediction Service (LPPS);

FIG. 3 depicts an example infrastructure equipment;

FIG. 4 depicts an example Multi-access Edge Computing (MEC) systemarchitecture;

FIG. 5 depicts example components of a computer platform;

FIG. 6 depicts example data collection layer;

FIG. 7 illustrates an example cell load prediction layer;

FIG. 8 illustrates an example scenario involving intra-cellcharacteristic predictions;

FIG. 9 illustrates an example cell transition prediction layer;

FIG. 10 illustrates an example cell transition graph;

FIG. 11 illustrates an example data fusion engine for predictingbandwidths;

FIG. 12 illustrates another example data fusion engine for predictingbandwidths;

FIGS. 13-17 illustrate example LPPS procedures;

FIG. 18 illustrates an example LPP protocol data unit; and

FIG. 19 depicts an example procedure for practicing various embodimentsdiscussed herein.

DETAILED DESCRIPTION

Disclosed embodiments are related to wireless communications, and inparticular, technologies for Link Quality Prediction (LQP) or LinkPerformance Prediction (LPP) (sometimes referred to as “network qualityprediction”). LQP/LPP are used to improve wireless network performanceby predicting future network behaviors/metrics (e.g., bandwidth (BW),latency, capacity, coverage holes, etc.) and making applications, userequipment (UE), and/or network infrastructure more aware of thesepredicted network behaviors/metrics. The LPP technology discussed hereinuses machine learning (ML) techniques and a rich set of historical andreal-time data feeds to dynamically predict the quality and/orperformance of any given radio link and optimize application levelbehaviors. This allows the applications/UEs/infrastructure to makeoperational decisions such as, for example, taking precautions wherethere are coverage holes, increasing throughput where there arehigh-performing cells, entering an idle or sleep mode in crowded oroverloaded cells, adjusting transmission power, adjusting antenna tiltand/or azimuth, and/or other like operational decisions. Theaforementioned applications may be user applications running on userequipment (UEs), core network functions in a mobile network operator'score network, and/or server-side applications running on one or moreservers in a datacenter or server farm. These LPPs provide improvedcustomer experience as well as improvements in network/signalingresource utilization/conservation, which in turn enables more optimalinfrastructure deployments. Embodiments herein are related to differentapproaches to making these forward-looking LPPs for different types ofnetwork behaviors in various scenarios. The LPP technology discussedherein can also be used for other network planning and management tasksto further improve network performance and reduce operating costs.

In various embodiments, the link performance analysis is divided intomultiple layers. Each prediction layer determines its own predictedperformance metrics, which are then fused together by an LPP layer orLPP engine to make a link performance prediction. Each layer runs one ormore ML algorithms or ML models, which are then used to determinerespective predicted performance metrics. Each prediction layer providesits respective predicted performance metrics to the LPP layer/enginethat fuses the results together to obtain an LPP. In embodiments,specific ML algorithms, or combinations of ML algorithms, are used ateach prediction layer to determine the respective predicted performancemetrics, and one or more layers may use different ML algorithms (orcombinations of ML algorithms) than those used by other predictionlayers. The LPP layer/engine generates and provides LPP indications torelevant applications/UEs/infrastructure to allow thoseapplications/UEs/infrastructure to tailor their operations accordingly.The various prediction layers and the LPP layer/engine may be located inone or more servers in a server farm/data center or in one or more edgeservers (e.g., MEC servers) deployed at the edge of a network. Otherembodiment may be described and/or claimed.

The technical approaches and/or the prediction methodologies discussedherein obtain inputs from a set of prediction layers, and determines aLPP for individual UEs based on the obtained inputs and an internalstate of the system. The LPP is communicated to the individual UEs,communicated to one or more network elements communicating with theindividual UEs, and/or network access node (NANs) to which theindividual UEs is/are attached. In general, the LPP is a “hint” or otherlike indicator that one or more applications operating on the individualUEs, network element(s), and/or NANs can use to adjust their mode ofoperation, internal behaviors, and/or signaling/communication resourcesbased on the LPP.

As examples, the LPP may be in the form of one or more of a BW, latency,jitter, round trip time (RTT), number of interrupts, out-of-orderdelivery of data packets, transmission power, bit error rate, BER,packet loss rate, PRR, SNR, SINR, SINAD ratio, BLER, RSSI, RSRP, RSRQ,channel interference measurements, thermal noise power measurements,received interference power measurements, network or cell load, arecommended or needed transmission power, and/or a prediction of anyother measurement or data type discussed herein. The LPP can be directlycommunicated (e.g., Mbps for BW), with some calculations (logarithmic,percentage, etc.) or in a discrete levels (e.g., a value of “1” for <100kbps, 2 for <500 kbps, and/or the like).

FIG. 1 illustrates an example edge computing environment 100, whichincludes different layers of communication occurring within theenvironment 100, starting from endpoint sensors or things layer 110(e.g., operating in an Internet of Things (IoT) network topology)comprising one or more IoT devices 111 (also referred to as edgeendpoints 110 or the like); increasing in sophistication to gateways orintermediate node layer 120 comprising one or more user equipment (UEs)121 a and 121 b (also referred to as intermediate nodes 120 or thelike), which facilitate the collection and processing of data fromendpoints 110; increasing in processing and connectivity sophisticationto access node layer 130 (or “edge node layer 130”) comprising aplurality of network access nodes (NANs) 131, 132, and 133 (collectivelyreferred to as “NANs 131-133” or the like) and a plurality of edgecompute nodes 136 a-c (collectively referred to as “edge compute nodes136” or the like) within an edge computing system 135; and increasing inconnectivity and processing sophistication to a backend layer 110comprising core network (CN) 142 and cloud 144. The processing at thebackend layer 110 may be enhanced by network services as performed by aremote application server 150 and/or other cloud services. Some or allof these elements may be equipped with or otherwise implement some orall aspects of the LPP embodiments discussed infra.

The environment 100 is shown to include end-user devices, such asintermediate nodes 120 and endpoints 110, which are configured toconnect to (or communicatively couple with) one or more multiplecommunication networks (also referred to as “access networks,” “radioaccess networks,” or the like) based on different access technologies(or “radio access technologies”) for accessing application services.These access networks may include one or more of NANs 131, 132, and/or133. The NANs 131-133 are arranged to provide network connectivity tothe end-user devices via respective links 103, 107 between theindividual NANs and the one or more UEs 111, 121.

As examples, the communication networks and/or access technologies mayinclude cellular technology such as LTE, MuLTEfire, and/or NR/5G (e.g.,as provided by Radio Access Network (RAN) node 131 and/or RAN nodes132), WiFi or wireless local area network (WLAN) technologies (e.g., asprovided by access point (AP) 133 and/or RAN nodes 132), and/or thelike. Different technologies exhibit benefits and limitations indifferent scenarios, and application performance in different scenariosbecomes dependent on the choice of the access networks (e.g., WiFi, LTE,etc.) and the used network and transport protocols (e.g., TransferControl Protocol (TCP), User Datagram Protocol (UDP), QUIC (sometimesreferred to as “Quick UDP Internet Connections”), Stream ControlTransmission Protocol (SCTP), Resource Reservation Protocol (RSVP),Virtual Private Network (VPN), Multi-Path TCP (MPTCP), Generic RoutingEncapsulation (GRE), GeoNetworking protocol, Basic Transport Protocol(BTP), etc.).

The intermediate nodes 120 include UE 121 a and UE 121 b (collectivelyreferred to as “UE 121” or “UEs 121”). In this example, the UE 121 a isillustrated as a vehicle UE, and UE 121 b is illustrated as a smartphone(e.g., handheld touchscreen mobile computing device connectable to oneor more cellular networks). However, these UEs 121 may comprise anymobile or non-mobile computing device, such as tablet computers,wearable devices, PDAs, pagers, desktop computers, laptop computers,wireless handsets, unmanned vehicles or drones, and/or any type ofcomputing device including a wireless communication interface.

The endpoints 110 include UEs 111, which may be IoT devices (alsoreferred to as “IoT devices 111”), which are uniquely identifiableembedded computing devices (e.g., within the Internet infrastructure)that comprise a network access layer designed for low-power IoTapplications utilizing short-lived UE connections. The IoT devices 111are any physical or virtualized, devices, sensors, or “things” that areembedded with hardware and/or software components that enable theobjects, devices, sensors, or “things” capable of capturing and/orrecording data associated with an event, and capable of communicatingsuch data with one or more other devices over a network with little orno user intervention. As examples, IoT devices 111 may be abioticdevices such as autonomous sensors, gauges, meters, image capturedevices, microphones, light emitting devices, audio emitting devices,audio and/or video playback devices, electro-mechanical devices (e.g.,switch, actuator, etc.), EEMS, ECUs, ECMs, embedded systems,microcontrollers, control modules, networked or “smart” appliances, MTCdevices, M2M devices, and/or the like. The IoT devices 111 can utilizetechnologies such as M2M or MTC for exchanging data with an MTC server(e.g., a server 150), an edge server 136 and/or edge computing system135, or device via a PLMN, ProSe or D2D communication, sensor networks,or IoT networks. The M2M or MTC exchange of data may be amachine-initiated exchange of data.

The IoT devices 111 may execute background applications (e.g.,keep-alive messages, status updates, etc.) to facilitate the connectionsof the IoT network. Where the IoT devices 111 are, or are embedded in,sensor devices, the IoT network may be a WSN. An IoT network describesan interconnecting IoT UEs, such as the IoT devices 111 being connectedto one another over respective direct links 105. The IoT devices mayinclude any number of different types of devices, grouped in variouscombinations (referred to as an “IoT group”) that may include IoTdevices that provide one or more services for a particular user,customer, organizations, etc. A service provider (e.g., anowner/operator of server 150, CN 142, and/or cloud 144) may deploy theIoT devices in the IoT group to a particular area (e.g., a geolocation,building, etc.) in order to provide the one or more services. In someimplementations, the IoT network may be a mesh network of IoT devices111, which may be termed a fog device, fog system, or fog, operating atthe edge of the cloud 144. Aspects of fog computing are discussed in'919 and '352.

As mentioned previously, the access networks provide networkconnectivity to the end-user devices 120, 110 via respective NANs131-133. The access networks may be Radio Access Networks (RANs) such asan NG RAN or a 5G RAN for a RAN that operates in a 5G/NR cellularnetwork, an E-UTRAN for a RAN that operates in an LTE or 4G cellularnetwork, or a legacy RAN such as a UTRAN or GERAN for GSM or CDMAcellular networks. The access network or RAN may be referred to as anAccess Service Network for WiMAX implementations. In some embodiments,all or parts of the RAN may be implemented as one or more softwareentities running on server computers as part of a virtual network, whichmay be referred to as a cloud RAN (CRAN), Cognitive Radio (CR), avirtual baseband unit pool (vBBUP), and/or the like. In theseembodiments, the CRAN, CR, or vBBUP may implement a RAN function split,wherein one or more communication protocol layers are operated by theCRAN/CR/vBBUP and other communication protocol entities are operated byindividual RAN nodes 131, 132. This virtualized framework allows thefreed-up processor cores of the NANs 131, 132 to perform othervirtualized applications, such as virtualized applications for LPPembodiments discussed herein.

The UEs 121, 111 may utilize respective connections (or channels) 103,each of which comprises a physical communications interface or layer.The connections 103 are illustrated as an air interface to enablecommunicative coupling consistent with cellular communicationsprotocols, such as 3GPP LTE, 5G/NR, Push-to-Talk (PTT) and/or PTT overcellular (POC), UMTS, GSM, CDMA, and/or any of the other communicationsprotocols discussed herein. In some embodiments, the UEs 111, 121 andthe NANs 131-133 communicate data (e.g., transmit and receive) data overa licensed medium (also referred to as the “licensed spectrum” and/orthe “licensed band”) and an unlicensed shared medium (also referred toas the “unlicensed spectrum” and/or the “unlicensed band”). To operatein the unlicensed spectrum, the UEs 111, 121 and NANs 131-133 mayoperate using LAA, enhanced LAA (eLAA), and/or further eLAA (feLAA)mechanisms. The UEs 121, 111 may further directly exchange communicationdata via respective direct links 105, which may be LTE/NR ProximityServices (ProSe) link or PC5 interfaces/links, or WiFi based links or apersonal area network (PAN) based links (e.g., IEEE 802.15.4 basedprotocols including ZigBee, IPv6 over Low power Wireless Personal AreaNetworks (6LoWPAN), WirelessHART, MiWi, Thread, etc.; WiFi-direct;Bluetooth/Bluetooth Low Energy (BLE) protocols).

The UEs 111, 121 are capable of measuring various signals ordetermining/identifying various signal/channel characteristics. Signalmeasurement may be performed for cell selection, handover, networkattachment, testing, and/or other purposes. The measurements collectedby the UEs 111, 121 may include one or more of the following: abandwidth (BW), network or cell load, latency, jitter, round trip time(RTT), number of interrupts, out-of-order delivery of data packets,transmission power, bit error rate, bit error ratio (BER), Block ErrorRate (BLER), packet loss rate, packet reception rate (PRR),signal-to-noise ratio (SNR), signal-to-noise and interference ratio(SINR), signal-plus-noise-plus-distortion to noise-plus-distortion(SINAD) ratio, peak-to-average power ratio (PAPR), Reference SignalReceived Power (RSRP), Received Signal Strength Indicator (RSSI),Reference Signal Received Quality (RSRQ), GNSS timing of cell frames forUE positioning for E-UTRAN or 5G/NR (e.g., a timing between a NAN131-133 reference time and a GNSS-specific reference time for a givenGNSS), GNSS code measurements (e.g., The GNSS code phase (integer andfractional parts) of the spreading code of the i^(th) GNSS satellitesignal), GNSS carrier phase measurements (e.g., the number ofcarrier-phase cycles (integer and fractional parts) of the i^(th) GNSSsatellite signal, measured since locking onto the signal; also calledAccumulated Delta Range (ADR)), channel interference measurement,thermal noise power measurement, received interference powermeasurement, and/or other like measurements. The RSRP, RSSI, and/or RSRQmeasurements may include RSRP, RSSI, and/or RSRQ measurements ofcell-specific reference signals, channel state information referencesignals (CSI-RS), and/or synchronization signals (SS) or SS blocks for3GPP networks (e.g., LTE or 5G/NR) and RSRP, RSSI, and/or RSRQmeasurements of various beacon, FILS discovery frames, or probe responseframes for IEEE 802.11 WLAN/WiFi networks. Other measurements may beadditionally or alternatively used, such as those discussed in 3GPP TS36.214 v15.4.0, 3GPP TS 38.215, IEEE 802.11, Part 11: “Wireless LANMedium Access Control (MAC) and Physical Layer (PHY) specifications,IEEE Std.”, and/or the like. The same or similar measurements may bemeasured or collected by the NANs 131-133.

The UE 121 b is shown to be configured to access an access point (AP)133 via a connection 107. In this example, the AP 133 is shown to beconnected to the Internet without connecting to the CN 142 of thewireless system. The connection 107 can comprise a local wirelessconnection, such as a connection consistent with any IEEE 802.11protocol, wherein the AP 133 would comprise a wireless fidelity (WiFi®)router. In embodiments, the UEs 121 and IoT devices 111 can beconfigured to communicate using suitable communication signals with eachother or with any of the AP 133 over a single or multicarriercommunication channel in accordance with various communicationtechniques, such as, but not limited to, an orthogonal frequencydivision multiplexing (OFDM) communication technique, a single-carrierfrequency division multiple access (SC-FDMA) communication technique,and/or the like, although the scope of the embodiments is not limited inthis respect. The communication technique may include a suitablemodulation scheme such as Complementary Code Keying (CCK); Phase-ShiftKeying (PSK) such as Binary PSK (BPSK), Quadrature PSK (QPSK),Differential PSK (DPSK), etc.; or Quadrature Amplitude Modulation (QAM)such as M-QAM; and/or the like.

The NANs 131 and 132 that enable the connections 103 may be referred toas “RAN nodes” or the like. The RAN nodes 131, 132 may comprise groundstations (e.g., terrestrial access points) or satellite stationsproviding coverage within a geographic area (e.g., a cell). The RANnodes 131, 132 may be implemented as one or more of a dedicated physicaldevice such as a macrocell base station, and/or a low power base stationfor providing femtocells, picocells or other like cells having smallercoverage areas, smaller user capacity, or higher bandwidth compared tomacrocells. In this example, the RAN node 131 is embodied as a NodeB,evolved NodeB (eNB), or a next generation NodeB (gNB), and the RAN nodes132 are embodied as relay nodes, distributed units, or Road Side Unites(RSUs). Any other type of NANs can be used.

Any of the RAN nodes 131, 132 can terminate the air interface protocoland can be the first point of contact for the UEs 121 and IoT devices111. In some embodiments, any of the RAN nodes 131/132 can fulfillvarious logical functions for the RAN including, but not limited to,radio network controller (RNC) functions such as radio bearermanagement, uplink and downlink dynamic radio resource management anddata packet scheduling, and mobility management. In embodiments, the UEs111, 121 can be configured to communicate using OFDM communicationsignals with each other or with any of the NANs 131, 132 over amulticarrier communication channel in accordance with variouscommunication techniques, such as, but not limited to, an OFDMAcommunication technique (e.g., for downlink communications) and/or anSC-FDMA communication technique (e.g., for uplink and ProSe or sidelinkcommunications), although the scope of the embodiments is not limited inthis respect.

For most cellular communication systems, the RNC function(s) operated bythe RAN or individual NANs 131-132 organize downlink transmissions(e.g., from any of the RAN nodes 131, 132 to the UEs 111, 121) anduplink transmissions (e.g., from the UEs 111, 121 to RAN nodes 131, 132)into radio frames (or simply “frames”) with 10 millisecond (ms)durations, where each frame includes ten 1 ms subframes. Eachtransmission direction has its own resource grid that indicate physicalresource in each slot, where each column and each row of a resource gridcorresponds to one symbol and one subcarrier, respectively. The durationof the resource grid in the time domain corresponds to one slot in aradio frame. The resource grids comprises a number of resource blocks(RBs), which describe the mapping of certain physical channels toresource elements (REs). Each RB may be a physical RB (PRB) or a virtualRB (VRB) and comprises a collection of REs. An RE is the smallesttime-frequency unit in a resource grid. The RNC function(s) dynamicallyallocate resources (e.g., PRBs and modulation and coding schemes (MCS))to each UE 111, 121 at each transmission time interval (TTI). A TTI isthe duration of a transmission on a radio link 103, 105, and is relatedto the size of the data blocks passed to the radio link layer fromhigher network layers.

The area or region to be supplied with wireless network service orconnectivity by the NAN 131-133 is divided into cells, each of whichhave a pattern dependent on the physical characteristics (e.g., terrain,physical objects or obstacles, etc.) and radio transmission/receptioncharacteristics. The cell patterns may be in the form of shapes, such ascircles, hexagons, squares, or the like, having a size that variesdepending, in part, on the radio transmission/reception characteristics.Each of these cells is assigned with multiple channels or frequencycarriers that are provided by a respective NAN 131, 132, 133. Thechannels or frequencies used in one cell can be reused in other cells,provided that the same frequencies are not reused in adjacent cells,which would cause co-channel interference. For example, a first NAN 131may provide an LTE cell in a frequency band (or overall cell bandwidth)of 600 MHz to 6 gigahertz (GHz) with channel BWs (or carrier BWs) of1.4, 3, 5, 10, 15, or 20 megahertz (MHz) (depending on the duplex modeof the frequency band), which may be aggregated together to create achannel BW up to 100 MHz (in LTE-Advance) or up to 640 MHz (inLTE-Advanced Pro). In a second example, a second NAN 131 may provide a5G/NR cell with a maximum carrier BW (or channel BW) of 100 MHz infrequency range 1 (FR1: 450 MHz to 6 GHz) or a maximum carrier BW (orchannel BW) of 400 MHz in frequency range 2 (FR2: 24.25 GHz to 52.6 GHz)that can be aggregated with a maximum bandwidth of 800 MHz. In each ofthe aforementioned examples, the exact frequency band and the channelBWs that can be used may depend on the country and/or regulatory regimein which the NAN 133 is located.

A given cell has a certain amount of radio resources within itsfrequency band that can be allocated to individual UEs 111, 121. Theamount of resources per cell may be expressed a number of PRBs per TTI,and the amount of available resources (e.g., non-occupied PRBs) dependson the traffic load of a cell. The amount of data that can betransmitted in a PRB depends in part on radio link quality. Radio linkquality may also change based on UE 121, 111 mobility within aparticular cell (referred to as “intra-cell mobility” or the like) andmobility between cells (referred to as “inter-cell mobility” or thelike). Additionally, radio signal properties/characteristics areaffected by interference from other radio signals and physical obstacles(e.g., tress, buildings, statues, etc.) blocking a line-of-sight (LoS)of radio transmitters or receivers. The amount of data that can betransmitted in a PRB affects the realized and/or perceived performanceof a wireless network or a given link 103, 105, 107. In other words, theradio signal performance properties/characteristics impact the BW and/ornetwork services that can be provided by individual cells and/orindividual NANs 131-133, as well as the resource consumption of the UEs111, 121 and the NANs 131-133 themselves. As discussed in more detailinfra, the LPP technology discussed herein is used to predict futureperformance and/or characteristics of the wireless interfaces 103, 105,107 based on various criteria.

The NANs 131, 132 may be configured to communicate with one another viarespective interfaces or links (not shown), such as an X2 interface forLTE implementations (e.g., when CN 142 is an Evolved Packet Core (EPC)),an Xn interface for 5G or NR implementations (e.g., when CN 142 is anFifth Generation Core (5GC)), or the like. The NANs 131 and 132 are alsocommunicatively coupled to CN 142. In embodiments, the CN 142 may be anevolved packet core (EPC) network, a NextGen Packet Core (NPC) network,a 5G core (5GC), or some other type of CN. The CN 142 may comprise aplurality of network elements, which are configured to offer variousdata and telecommunications services to customers/subscribers (e.g.,users of UEs 121 and IoT devices 111) who are connected to the CN 142via a RAN. The components of the CN 142 may be implemented in onephysical node or separate physical nodes including components to readand execute instructions from a machine-readable or computer-readablemedium (e.g., a non-transitory machine-readable storage medium). In someembodiments, Network Functions Virtualization (NFV) may be utilized tovirtualize any or all of the above-described network node functions viaexecutable instructions stored in one or more computer-readable storagemediums (described in further detail infra). A logical instantiation ofthe CN 142 may be referred to as a network slice, and a logicalinstantiation of a portion of the CN 142 may be referred to as a networksub-slice. NFV architectures and infrastructures may be used tovirtualize one or more network functions, alternatively performed byproprietary hardware, onto physical resources comprising a combinationof industry-standard server hardware, storage hardware, or switches. Inother words, NFV systems can be used to execute virtual orreconfigurable implementations of one or more CN 142components/functions.

The CN 142 is shown to be communicatively coupled to an applicationserver 150 and a network 150 via an IP communications interface 155. theone or more server(s) 150 comprise one or more physical and/orvirtualized systems for providing functionality (or services) to one ormore clients (e.g., UEs 121 and IoT devices 111) over a network (e.g.,cloud 144). The server(s) 150 may include various computer devices withrack computing architecture component(s), tower computing architecturecomponent(s), blade computing architecture component(s), and/or thelike. The server(s) 150 may represent a cluster of servers, a serverfarm, a cloud computing service, or other grouping or pool of servers,which may be located in one or more datacenters. The server(s) 150 mayalso be connected to, or otherwise associated with one or more datastorage devices (not shown). Moreover, the server(s) 150 may include anoperating system (OS) that provides executable program instructions forthe general administration and operation of the individual servercomputer devices, and may include a computer-readable medium storinginstructions that, when executed by a processor of the servers, mayallow the servers to perform their intended functions. Suitableimplementations for the OS and general functionality of servers areknown or commercially available, and are readily implemented by personshaving ordinary skill in the art. Generally, the server(s) 150 offerapplications or services that use IP/network resources. As examples, theserver(s) 150 may provide traffic management services, cloud analytics,content streaming services, immersive gaming experiences, socialnetworking and/or microblogging services, and/or other like services. Inaddition, the various services provided by the server(s) 150 may includeinitiating and controlling software and/or firmware updates forapplications or individual components implemented by the UEs 121 and IoTdevices 111. The server(s) 150 can also be configured to support one ormore communication services (e.g., Voice-over-Internet Protocol (VoIP)sessions, PTT sessions, group communication sessions, social networkingservices, etc.) for the UEs 121 and IoT devices 111 via the CN 142.

The cloud 144 may represent a cloud computing service, the Internet, alocal area network (LAN) or a wide area network (WAN) includingproprietary and/or enterprise networks for a company or organization, orcombinations thereof. The cloud 144 may be a network that comprisescomputers, network connections among the computers, and softwareroutines to enable communication between the computers over networkconnections. In this regard, the cloud 144 comprises one or more networkelements that may include one or more processors, communications systems(e.g., including network interface controllers, one or moretransmitters/receivers connected to one or more antennas, etc.), andcomputer readable media. Examples of such network elements may includewireless access points (WAPs), home/business servers (with or without RFcommunications circuitry), routers, switches, hubs, radio beacons, basestations, picocell or small cell base stations, backbone gateways,and/or any other like network device. Connection to the cloud 144 may bevia a wired or a wireless connection using the various communicationprotocols discussed infra. More than one network may be involved in acommunication session between the illustrated devices. Connection to thecloud 144 may require that the computers execute software routines whichenable, for example, the seven layers of the OSI model of computernetworking or equivalent in a wireless (cellular) phone network. Cloud144 may be used to enable relatively long-range communication such as,for example, between the one or more server(s) 150 and one or more UEs121 and IoT devices 111. In some embodiments, the cloud 144 mayrepresent the Internet, one or more cellular networks, local areanetworks, or wide area networks including proprietary and/or enterprisenetworks, TCP/Internet Protocol (IP)-based network, or combinationsthereof. In such embodiments, the cloud 144 may be associated withnetwork operator who owns or controls equipment and other elementsnecessary to provide network-related services, such as one or more basestations or access points, one or more servers for routing digital dataor telephone calls (e.g., a core network or backbone network), etc. Thebackbone links 155 may include any number of wired or wirelesstechnologies, and may be part of a LAN, a WAN, or the Internet. In oneexample, the backbone links 155 are fiber backbone links that couplelower levels of service providers to the Internet, such as the CN 412and cloud 144.

In embodiments, the edge compute nodes 136 may include or be part of aMEC system 135, which is discussed in more detail infra with respect to(w.r.t) FIG. 4 . It should be understood that the disclosed MEC systemsand services deployment examples are only one illustrative example ofedge computing systems/networks 135, and that the example embodimentsdiscussed herein may be applicable to many other edgecomputing/networking technologies in various combinations and layouts ofdevices located at the edge of a network. Examples of such other edgecomputing/networking technologies that may implement the LPP embodimentsmay include Content Delivery Networks (CDNs) (also referred to as“Content Distribution Networks” or the like); Mobility Service Provider(MSP) edge computing and/or Mobility as a Service (MaaS) providersystems; Nebula edge-cloud systems; Fog computing systems; Cloudletedge-cloud systems; Mobile Cloud Computing (MCC) systems; Central OfficeRe-architected as a Datacenter (CORD), mobile CORD (M-CORD) and/orConverged Multi-Access and Core (COMAC) systems; the Open Radio AccessNetwork (O-RAN) framework provided by the O-RAN Alliance™; Multi-AccessManagement Services (MAMS) framework (see e.g., IETF RFC 8743); the 3GPPSystem Architecture for enabling Edge Applications (see e.g., 3GPP TS23.558, 3GPP TS 23.548, 3GPP TS 23.501, and the like); and/or the like.Further, the techniques disclosed herein may relate to other IoT edgenetwork systems and configurations, and other intermediate processingentities and architectures may also be used to practice the LPP aspectsdiscussed herein. As shown by FIG. 1 , each of the NANs 131, 132, and133 are co-located with edge compute nodes (or “edge servers”) 136 a,136 b, and 136 c, respectively; theses implementations may be small-cellclouds (SCCs), mobile micro clouds (MCCs), and/or follow-me clouds (FMC)as described in '919 and '352.

In any of the aforementioned embodiments and/or implementations, theedge servers 136 provide a distributed computing environment forapplication and service hosting, and also provide storage and processingresources so that data and/or content can be processed in closeproximity to subscribers (e.g., users of UEs 121, 111) for fasterresponse times the edge servers 136 also support multitenancy run-timeand hosting environment(s) for applications, including virtual applianceapplications that may be delivered as packaged VM images, middlewareapplication and infrastructure services, content delivery servicesincluding content caching, mobile big data analytics, and computationaloffloading, among others. Computational offloading involves offloadingcomputational tasks, workloads, applications, and/or services to theedge servers 136 from the UEs 111/121, CN 142, cloud 144, and/orserver(s) 150, or vice versa. For example, a device application orclient application operating in a UE 121/111 may offload applicationtasks or workloads to one or more edge servers 136. In another example,an edge server 136 may offload application tasks or workloads to one ormore UE 121/111 (e.g., for distributed ML computation or the like).

As alluded to previously, various aspects of the LPP embodiments may beperformed by one or more server(s) 150, by one or more NFs in the CN142, by cloud 144 (or one or more cloud computing nodes within the cloud144), and/or by one or more edge compute nodes 136. The collection orcombination of systems or devices that perform the LPP embodimentsdiscussed herein may be collectively referred to as an “LPP service,”which is discussed in more detail w.r.t FIG. 2 .

FIG. 2 shows example logical components and interaction points of an LPPservice (LPPS) 200. As shown, for the illustrated embodiments, the LPPS200 includes an LPP layer 202 and a plurality of prediction layers 225-1to 225-N (collectively referred to as “prediction layers 225” or thelike). In the illustrated embodiment, the components of the LPPS 200interact with one or more elements in the edge computing environment 100discussed previously w.r.t FIG. 1 .

The LPPS 200 predicts how network performance (e.g., performance ofenvironment 100) changes over time with a relatively high degree ofconfidence. For example, the LPPS 200 is capable of predicting linkperformance in time and space, which allows applications, UEs 111, 121,and/or network infrastructure able to shift delay tolerant traffic intime and/or space in order to smooth out peak demand and improve overallnetwork resource utilization. The ability to forecast and communicatelink performance predictions can also help applications, UEs 111, 121,and/or network infrastructure modify their behavior to account forcongested or otherwise sub-optimal network conditions.

The LPPS 200 uses spatial and temporal (spatio-temporal) historical dataand/or real-time data to predict link quality. The spatio-temporalhistorical data is data related to the performance experienced overmultiple locations (e.g., space) and at multiple time instances (e.g.,temporal). The spatio-temporal historical data provides ability tolocate performance at specific location and time. Real-time dataincludes data/information such as live traffic status (e.g., vehicles ona given roadway or the like), abnormal events (e.g., natural disastersand the like), network load (e.g., resource utilization of NANs 131,132, 133, edge compute nodes 136, and the like), radio conditions (e.g.,amount of occupied radio resources, amount of signaling taking placeover the radio links 103, 105, 107, interference measurements, etc.), UE111, 121 location (e.g., geographic position within a given cell), UE111, 121 motion/mobility (e.g., speed and direction of travel within agiven cell or between cells), and/or routing information (e.g., numberand types of hops between source and destination nodes or the like), ifknown. The LPPS 200 uses the historical and real-time data collectedacross a wide range of mobile devices (e.g., UEs 111, 121) and networkelements (e.g., NANs 131, 132, and 133, edge compute nodes 136, corenetwork elements in CN 142, etc.), allowing the LPPS 200 to build a viewof the network performance that users and services will likelyexperience over time. Consumers (e.g., UEs 111, 121 and NANs 131, 132,133, application/service providers, etc.) can subscribe to predictionsthat have direct relevance to network performance and/or their serviceperformance. The LPPS 200 responds to the consumer indicating anysignificant changes in performance over time. These embodiments arediscussed in more detail infra w.r.t FIGS. 13-17 .

Each prediction layer 225 provide functionality independent offunctionality provided by other layers 225, as well as differentfunctionality of the LPP layer 202. For example, the LPP layer 202 mayimplement a data fusion engine (also referred to as an “LPP engine”)(discussed in more detail infra), the prediction layer 225-1 mayimplement one or more first ML models/algorithms to generate a firsttype of predicted performance metrics, the prediction layer 225-2 mayimplement one or more second ML models/algorithms to generate a secondtype of predicted performance metrics, and so forth to the predictionlayer 225-N, which may implement one or more Nth ML models/algorithms togenerate an Nth type of predicted performance metrics (where N is anumber).

Each prediction layer 225 runs one or more ML models to determinerespective predicted performance metrics, and provides their respectivepredicted performance metrics to the LPP layer 202. Machine learningalgorithms build mathematical models, referred to as a “machine learningmodel” or simply “model”, based on sample data, known as “trainingdata”, in order to make predictions or decisions without beingexplicitly programmed to perform such tasks. Generally, an ML algorithmis a computer program that learns from experience w.r.t some task and/orsome performance measure, and an ML model is an object or data structurecreated after an ML algorithm is trained with one or more trainingdatasets. After training, the ML model may be used to make predictionson new datasets. Although the term “ML algorithm” refers to differentconcepts than the term “ML model,” these terms as discussed herein maybe used interchangeably for the purposes of the present disclosure. Inembodiments, specific ML algorithms, or combinations of ML algorithms,are used at individual prediction layers 225 to determine respectivepredicted performance metrics, and one or more layers 225 may usedifferent ML algorithms (or combinations of ML algorithms) than thoseused by other prediction layers 225. Examples implementations ofdifferent prediction layers 225 are discussed infra with regard to FIGS.6-12 .

At least one of the layers 225 is responsible for collecting data fromone or more UEs 111/121 and/or NANs 131-133 in environment 100, whichmay be processed by that layer 225 and provided to other layers 225 fordetermining their respective predicted performance metrics. In suchembodiments, the layers 225 that are responsible for data collection mayobtain data from applications, components, or the like at the datasources (e.g., the UEs 111, 121, NANs 131-133, etc.) that collect datafrom system software (e.g., operating systems, device drivers, firmware,utility applications, etc.) and/or various user/client applicationsoperating on those devices via a suitable API, middleware, softwareglue, proxy applications, trusted applications, etc., and provide thecollected data to the data collection layer(s) 225. In some embodiments,these applications, components, etc., may be custom plug-ins configuredto interact with, and collected data/metrics from the system software,other applications, etc.

The LPP layer 202 obtains the predicted performance metrics from theprediction layers 225 and fuses the predicted performance metricstogether to obtain an LPP for an LPPS consumer (not shown by FIG. 2 ).The LPP layer 202 may include any suitable technology to fuse thepredicted performance metrics provided by the prediction layers 225.Data fusion is a process of integrating and/or combining data collectedfrom multiple sources at different spatial and temporal scales in orderto make inferences about that data. In some embodiments, these“inferences” may be the link performance predictions, while in otherembodiments, the LPP layer 202 implements suitable MLmodel(s)/algorithm(s) to generate the link performance predictions basedon the inferences.

For example, the LPP layer 202 may be trained during a training phaseusing predetermined data inputs to establish model parameters (e.g.,initial state distribution) and to associate at least some of the stateswith inferences having meaningful significance. The established modelparameters are stored in memory (e.g., memory circuitry 320 of FIG. 3 orthe like). Then during an operational phase, the LPP layer 202 performsdata fusion on real (live) data from the prediction layers 225, and inorder to increase the accuracy of the model, continually modifies theestablished model parameters as necessary based on a comparison betweena prediction and what is actually received.

In various embodiments, the LPP layer 202 (or the LPP engine) isconfigured to perform Multi-Cell Multi-Layer (MCML) data fusiontechniques. In such embodiments, the LPP layer 202 takes data from oneor more prediction layers 225 and combines that data with data from oneor more other prediction layers 225 to derive the link performanceprediction for corresponding LPPS consumers. In one MCML example, theLPP layer 202 may take an output from a cell transition prediction layer(see e.g., FIGS. 9-10 ), which is in the form of expected cells a UE111, 121 will visit, and pairs that output with outputs provided by acell load prediction layer (see e.g., FIG. 7 ) to predict a performanceof individual cells based on mobility of the UE 111, 121. In a secondMCML example, network data and/or parameters (e.g., a mobile networkassociated with CN 142 of FIG. 1 ), data from traffic and/or mobilitypatterns, subscriber information, and data from GPS are fed in todifferent prediction layers 225 for training and prediction ofperformance metrics from those prediction layers 225 are fused topredict final network performance at a particular time/date. Asmentioned previously, each prediction layer 225 can be trained with datafrom different sources (e.g., network, traffic, GPS, subscriberinformation).

MCML data fusion accounts for different operational states, operationalcontexts, and/or mobility states. For example, as discussed in moredetail infra, a cell transition prediction layer (see e.g., FIGS. 9-10 )may be used to predict the cells that a UE 111, 121 will visit atparticular time instances based on a current cell in which the UE 111,121 is camping, a previous cell visited by the UE 111, 121, and traveldirection and velocity measurements. When the UE 111, 121 is stationary(not moving), the link performance prediction is based on a currentcell's behavior, and the LPP layer 202 fuses the current cell'scharacteristics and cell load, including real-time and predicted futurebehavior(s) and/or load(s), to obtain the LPP. When the UE 111, 121 ismoving in a relatively dense area (e.g., where cell sizes are relativelysmall, such as in a city), and the predicted cell behaviors andpredicted cell load(s) of each cell predicted to be visited by the UE111, 121 is combined (fused) together for the LPP. When the UE 111, 121is moving in a relatively sparse area (e.g., where cell sizes arerelatively large, such as in a rural area), the link performanceprediction is based on intra-cell behavior(s) (e.g., predicted signalstrength, signal quality, power changes, etc., within individual cells;see e.g., FIG. 8 ) for each cell predicted to be visited by the UE 111,121, and the intra-cell behavior(s) of each predicted cell is combined(fused) with respective predicted cell behaviors and respectivepredicted cell load(s). When the UE 111, 121 is moving using anavigation application, the cell transition prediction layer predictsthe cell transitions using a cell movement/mobility pattern determinedfrom obtained route/journey data, navigation settings, and/or otherinformation from the navigation application, and each cell predicted tobe visited by the UE 111, 121 is combined (fused) with respectivepredicted cell behaviors and respective predicted cell load(s). In theseembodiments, if network topology information and/or backhaul linkperformance predictions are available, then the predicted cellbehavior(s) and/or load(s) may be combined (fused) with these additionalnetwork topology predictions and/or backhaul link predictions.

In some embodiments, MCML data fusion involves the LPP layer 202 (or LPPengine) requesting, from the cell transition prediction layer for a UE111, 121, a prediction of various cell that the UE 111, 121 may visitgiven a current cell. These predictions may be based on spatio-temporalhistory data associated with the UE 111, 121 (e.g., mobility data)and/or the current cell. The cell transition prediction layer returnsdata including the expected future cells the UE 111, 121 may visit, theexpected probability of visiting each cell in a given region, apredicted time interval (or amount of time) for the UE 111, 121 totravel to each cell, and an predicted amount time that the UE 111, 121will remain in each cell. Then, the LPP layer 202 requests predictedcell/link characteristics and/or behaviors for each cell indicated bythe cell transition prediction layer at the time interval the UE 111,121 is expected to enter each cell and the amount of time the UE 111,121 is predicted to be in each cell. The LPP layer 202 combines (fuses)the returned predicted cell/link characteristics and/or behaviors foreach cell to determine a predicted link performance (e.g., the LPP)given the current and future cell load as well as expected deviation(s).The LPP layer 202 now knows the probability that the UE 111, 121 willenter or travel through a particular cell, the predicted amount of timethe UE 111, 121 will take to enter the particular cell, the amount ofpredicted time to be spent in the particular cell, as well as the LPPfor each cell at each time instance. The LPP layer 202 then looks at atime window from a current time to some future time instance (e.g. 30seconds, 1 minutes, 2 minutes, etc., from the current time depending onhow steady the link is), and breaks this time window into time intervals(e.g. 1 second). The time interval for the UE 111, 121 to reachrespective cells is added to the time window with respectivecharacteristics/loads, and the probability that the UE 111, 121 willvisit the respective cells. Then, the LPP layer 202 runs through thetime window, and filters out probabilities that are deemed to be too lowfor consideration. As an example, changes detected to be larger than acertain level (e.g., 5%, 10% deviation, etc.) may be filtered out. Thedetermined LPP for each remaining portions of the time window may besent to the UE 111, 121 or other LPPS consumer, taking into account theamount of delay and predicted location of the UE 111, 121 (or other LPPSconsumer).

Additionally or alternatively, one or more other data fusion techniquesmay be used to combine or fuse the predicted performance metrics.Examples of these known data fusion techniques may include, but are notlimited to, data association techniques (e.g., Nearest Neighbors,K-Means Probabilistic Data Association (PDA) and/or PDA Filter (PDAF),Principle Component Analysis (PCA), Joint Probabilistic Data Association(JPDA), Distributed JPDA (JPDA-D), Multiple Hypothesis Test (MHT),Distributed MHT (MHT-D), graphical modeling, and/or the like), stateestimation techniques (e.g., maximum likelihood, maximum posterior,Kalman filter, distributed Kalman filter, particle filter, distributedparticle filter, covariance intersection, covariance union, OptimalTheory, Regularization, Uncertainty Ellipsoids, and/or the like),decision fusion techniques (e.g., Bayesian methods (e.g., evidencetheory, robust statistics, recursive operators, etc.), Dempster-ShaferInference, Abductive Reasoning, Semantic methods, and/or the like),intelligent aggregation techniques (e.g., one or more ML techniques suchas neural networks (including any neural network discussed herein),genetic algorithms, fuzzy logic, etc.), and/or any other suitable datafusion techniques.

The LPPs are used to generate the LPP notifications that the LPPS 200provides to LPPS consumers such as applications, UEs 111/121, and/orNANs 131-133, which allow the LPPS consumers to tailor their operationsaccordingly. The LPP notifications, in one embodiment, are conceptuallysimilar to traffic notifications provided by a navigation application orvehicular driving applications. While the traffic notifications provideup-to-date information about current and forecasted traffic conditions,the LPP notifications provide information about current and forecastedlink quality or performance.

The LPPS 200 may provide intelligent network management services tonetwork operators. For example, network operators may use the LPPnotifications to autonomously manage transmitter power, antennadirection, angle, and tilt; and other parameters of the NANs 131, 132,133. Additionally or alternatively, the link performance predictions inthe LPP notifications may be fed into for Self-Organizing Network (SON)functions in LTE or 5G/NR implementations. In some embodiments, the LPPS200 may be used for network degradation control, which entailsidentifying instances of poor performance and troubleshooting. (e.g.,identifying when equipment should be repaired or replaced).

The LPPS 200 may be used for efficient small cell backhaul planning. Forexample, the link performance predictions in the LPP notifications maybe used to identify locations to deploy small cells (e.g., RAN nodes132, AP 133, or the like) to enhance coverage and/or capacity whiletaking into account the associated backhaul and power requirements forsuch deployments. Additionally or alternatively, in some embodiments,the LPPS 200 may be used for backhaul link resource allocation. In theseembodiments, the link performance predictions may indicate the load orusage of different backhaul links at different time periods on differentdays, and network operators can reduce operating costs by powering downbackhaul links which are expected to require low usage at particulartimes before powering them back up at predicted peak usage times.

By providing the LPP notifications to users, network operators, andservice providers, network operators and service providers may tailortheir applications/services to utilize network resources in a moreefficient manner than using conventional technologies. As an example,individual NANs 131, 132, 133 may schedule background traffic (e.g.,paging, control signaling, heartbeat signaling, and/or other liketraffic/signaling that takes place even when there is no user orapplication interaction with a UE 111, 121) for transmission duringpeaks in network performance. In this example, the peaks in networkperformance may be based on a predicted time and/or mobility when a UE111, 121 will be proximate to a serving NAN 131, 132, 133 or a predictedperiod during which the network should have sufficient capacityheadroom.

The LPP notifications may also be used by network operators and serviceproviders to improve Quality of Service (QoS) and/or Quality ofExperience (QoE), which are traditionally associated with networkperformance metrics. Static network performance metrics only provide apartial, snapshot view of the QoS and/or QoE. Using the LPPnotifications, network operators and service providers can adjusttraffic routes, mode of operation, and/or other parameters to optimizeQoS and QoE since they will have advance warning regarding anysignificant changes in expected network performance.

The LPPS 200 itself may be an abstraction layer between serviceproviders (e.g., operators/owners of server(s) 150 of FIG. 1 ) and theunderlying mobile access network (e.g., an owner/operator of CN 142and/or some or all of the NANs 131, 132) giving an abstracted view ofthe access network link quality, which allows service providers and/orapplication developers to make proactive decisions to improve QoS/QoE.In a first example, a service provider is a content streaming serviceand/or platform that uses CDN edge compute nodes 130 to stream contentto UEs 121. In this example, the service provider uses the LPPnotifications to adapt streaming buffers operated by the CDN edgecompute nodes 130 to cover for poor coverage areas (e.g., coverageholes) that will likely be encountered by travelling UEs 121. Using theLPP notifications from the LPPS 200, the CDN edge compute nodes 130 maypre-fetch and stream required content (e.g., for storage in a localbuffer at the UEs 121) prior to a UE 121 entering or travelling througha poor coverage area (or coverage hole). Additionally or alternatively,content may be pre-fetched an loaded to CDN edge compute nodes 130 alonga predicted travel path/route of a UE 121 (e.g., closer to the UE's 121anticipated point of consumption), and the amount of content streamed tothe UE 121 at different points along the predicted path/route may bebased on predicted network performance at those different points.

In a second example, a service provider provides over-the-top (OTT)real-time services including, for example, television, messaging (e.g.,instant messaging, online chats, etc.), and voice calling. In thisexample, the service provider uses the LPP notifications to provideadvance warnings to users indicating when an OTT connection will likelybe lost, and how long the connection may take to be reconnected. In athird example, a service provider provides interactive map andnavigation services, which provides to UEs 121 a turn-by-turn directionsfor a selected route. In this example, the service provider may use theLPP notifications to optimize the travel routes based on physicaltraffic (e.g., volume of vehicles travelling in a certain road orhighway) and/or predicted network connectivity, which may be useful forsemi-autonomous or fully-autonomous vehicle systems. Furthermore, theseoptimizations may be useful in industrial contexts, such as in “smartfactories” or manufacturing plants, where mobile IoT devices 111 can useLPP notifications for route optimization purposes. In a fourth example,a mobile network operator (e.g., an owner/operator of CN 142 and/or someor all of the NANs 131, 132) uses to guarantee a certain level ofnetwork performance (e.g., Service Level Guarantees) forenterprise-level customers. In this example, the mobile network operatormay use the LPP notifications and/or the LPPS 200 to quantify theirnetwork performance at varying levels of granularities showing theircustomers that they can provide a consistent high-quality QoS/QoE.

In some embodiments, the layers 225/202 may communicate with one anotherthrough one or more connectors 206. The connectors 206 may be softwareconnectors that connect the various layers 202/225 of the LPPS 200 toone another so each layer 202/225 does not need to know the underlyingdetails of other layers 202/225. The connectors 206 facilitate messagepassing/routing between individual layers 202/225, which may includeencapsulating data from one layer 202/225 for consumption by an intendeddestination layer 202/225 or components thereof. As an example, theconnectors 206 may be an exogenous connector, which coordinates andcontrols a totality of interactions/communications of the layers 202/225where the connectors 206 perform the method or procedure calls on behalfof a requesting/calling layer 202/225. Additionally or alternatively,the connectors 206 may be middleware or “software glue,” which connectstwo or more separate components by translating or adaptinginstructions/commands obtained from one layer 202/225 intoinstructions/commands that can be understood by another layer 202/225.In these ways, individual layers 225/202 may be replaced withnew/different layers 225/202 without requiring each remaining layer225/202 to be updated to communicate with the new/different layers225/202. Therefore, the LPPS 200 may provide relatively easy abstractionsince each layer 225/202 is loosely coupled from one another.Additionally, in some embodiments (e.g., where one or more of the layers225 are operated by different edge servers 130), the connectors 206 mayoperate on top of one or more communication protocols, such as thosediscussed herein.

In some embodiments, the LPPS 200 may be implemented as a centralizedservice wherein the various prediction layers 225 and/or the LPP layer202 are located in one or more servers in one or more server farms ordata centers (e.g., individual servers 150 of FIG. 1 ). In otherembodiments, the LPPS 200 may be implemented as an edge computingservice wherein the various prediction layers 225 and/or the LPP layer202 are located in one or more edge servers 136 deployed at the edge ofa network (e.g., CN 142, cloud 144, or the like). In one exampleimplementation, the plurality of prediction layers 225 and the LPP layer202 are operated by the cloud 144 of FIG. 1 , such as by individualcloud compute nodes in the cloud 144. In another example implementation,each of the prediction layers 225 are operated by individual edgecompute nodes 136, and the LPP layer 202 is operated by the cloud 144.In another example implementation, each of the prediction layers 225 aredistributed across multiple edge compute nodes 136. In another exampleimplementation, each edge compute node 136 operates a respective LPPS200. In any of the aforementioned implementations, each prediction layer225 and the LPP layer 202 may be operated in respective VMs and/orcontainers (e.g., Docker® containers, Kubernetes™ provided by the CloudNative Computing Foundation™, Linux Containers (LXC), etc.) in one ormore cloud servers and/or edge compute nodes 136. Other implementationsare possible in other embodiments.

FIG. 3 illustrates an example of infrastructure equipment 300 (or“system 300”), which may be implemented as a base station, radio head,access network node (e.g., the edge nodes 130 shown of FIG. 1 ), edgecompute nodes 136, server(s) 150, and/or any other element/devicediscussed herein. In other examples, the system 300 could be implementedin or by an intermediate node 120 or endpoint 110. The system 300includes application circuitry 305, baseband circuitry 310, one or moreradio front end modules (RFEMs) 315, memory circuitry 320, powermanagement integrated circuitry (PMIC) 325, power tee circuitry 330,network controller circuitry 335, network interface connector 340,positioning circuitry 345, and user interface 350. In some embodiments,the device 300 may include additional elements such as, for example,memory/storage, display, camera, sensor, or IO interface. In otherembodiments, the components described below may be included in more thanone device. For example, said circuitries may be separately included inmore than one device for CRAN, CR, vBBU, or other like implementations.

Application circuitry 305 includes circuitry such as, but not limited toone or more processors (or processor cores), cache memory, and one ormore of low drop-out voltage regulators (LDOs), interrupt controllers,serial interfaces such as SPI, I²C or universal programmable serialinterface module, real time clock (RTC), timer-counters includinginterval and watchdog timers, general purpose 10, memory cardcontrollers such as Secure Digital (SD) MultiMediaCard (MMC) or similar,Universal Serial Bus (USB) interfaces, Mobile Industry ProcessorInterface (MIPI) interfaces and Joint Test Access Group (JTAG) testaccess ports. The processors (or cores) of the application circuitry 305may be coupled with or may include memory/storage elements and may beconfigured to execute instructions stored in the memory/storage toenable various applications or operating systems to run on the system300. In some implementations, the memory/storage elements may be on-chipmemory circuitry, which may include any suitable volatile and/ornon-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory,solid-state memory, and/or any other type of memory device technology,such as those discussed herein.

The processor(s) of application circuitry 305 may include, for example,one or more processor cores (CPUs), one or more application processors,one or more graphics processing units (GPUs), one or more reducedinstruction set computing (RISC) processors, one or more Acorn RISCMachine (ARM) processors, one or more complex instruction set computing(CISC) processors, one or more DSPs, one or more FPGAs, one or morePLDs, one or more ASICs, one or more microprocessors or controllers, orany suitable combination thereof. In some embodiments, the applicationcircuitry 305 may comprise, or may be, a special-purposeprocessor/controller to operate according to the various embodimentsherein. As examples, the processor(s) of application circuitry 305 mayinclude one or more Intel Pentium®, Core®, or Xeon® processor(s);Advanced Micro Devices (AMD) Ryzen® processor(s), Accelerated ProcessingUnits (APUs), or Epyc® processors; ARM-based processor(s) licensed fromARM Holdings, Ltd. such as the ARM Cortex-A family of processors and theThunderX2® provided by Cavium™, Inc.; a MIPS-based design from MIPSTechnologies, Inc. such as MIPS Warrior P-class processors; and/or thelike. In some embodiments, the system 300 may not utilize applicationcircuitry 305, and instead may include a special-purposeprocessor/controller to process IP data received from an EPC or 5GC, forexample.

In some implementations, the application circuitry 305 may include oneor more hardware accelerators, which may be microprocessors,programmable processing devices, or the like. The one or more hardwareaccelerators may include, for example, computer vision (CV) and/or deeplearning (DL) accelerators. As examples, the programmable processingdevices may be one or more field-programmable gate arrays (FPGAs);programmable logic devices (PLDs) such as complex PLDs (CPLDs),high-capacity PLDs (HCPLDs), and the like; ASICs such as structuredASICs and the like; programmable SoCs (PSoCs); and/or the like. In suchimplementations, the circuitry of application circuitry 305 may compriselogic blocks or logic fabric, and other interconnected resources thatmay be programmed to perform various functions, such as the procedures,methods, functions, etc. of the various embodiments discussed herein. Insuch embodiments, the circuitry of application circuitry 305 may includememory cells (e.g., erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), flashmemory, static memory (e.g., static random access memory (SRAM),anti-fuses, etc.)) used to store logic blocks, logic fabric, data, etc.in look-up-tables (LUTs) and the like.

In some implementations, such as implementations where subsystems of theedge nodes 130, intermediate nodes 120, and/or endpoints 110 of FIG. 1are individual software agents or AI agents, each agent is implementedin a respective hardware accelerator that are configured withappropriate bit stream(s) or logic blocks to perform their respectivefunctions. In these implementations, processor(s) and/or hardwareaccelerators of the application circuitry 305 may be specificallytailored for operating the agents and/or for machine learningfunctionality, such as a cluster of AI GPUs, tensor processing units(TPUs) developed by Google® Inc., a Real AI Processors (RAPs™) providedby AlphaICs®, Nervana™ Neural Network Processors (NNPs) provided byIntel® Corp., Intel® Movidius™ Myriad™ X Vision Processing Unit (VPU),NVIDIA® PX™ based GPUs, the NM500 chip provided by General Vision®,Hardware 3 provided by Tesla®, Inc., an Epiphany™ based processorprovided by Adapteva®, or the like. In some embodiments, the hardwareaccelerator may be implemented as an AI accelerating coprocessor, suchas the Hexagon 685 DSP provided by Qualcomm®, the PowerVR 2NX Neural NetAccelerator (NNA) provided by Imagination Technologies Limited®, theNeural Engine core within the Apple® A11 or A12 Bionic SoC, the NeuralProcessing Unit within the HiSilicon Kirin 970 provided by Huawei®,and/or the like.

The baseband circuitry 310 may be implemented, for example, as asolder-down substrate including one or more integrated circuits, asingle packaged integrated circuit soldered to a main circuit board or amulti-chip module containing two or more integrated circuits. Thebaseband circuitry 310 includes one or more processing devices (e.g.,baseband processors) to carry out various protocol and radio controlfunctions. Baseband circuitry 310 may interface with applicationcircuitry of system 300 for generation and processing of basebandsignals and for controlling operations of the RFEMs 315. The basebandcircuitry 310 may handle various radio control functions that enablecommunication with one or more radio networks via the RFEMs 315. Thebaseband circuitry 310 may include circuitry such as, but not limitedto, one or more single-core or multi-core processors (e.g., one or morebaseband processors) or control logic to process baseband signalsreceived from a receive signal path of the RFEMs 315, and to generatebaseband signals to be provided to the RFEMs 315 via a transmit signalpath. In various embodiments, the baseband circuitry 310 may implement areal-time OS (RTOS) to manage resources of the baseband circuitry 310,schedule tasks, etc. Examples of the RTOS may include Operating SystemEmbedded (OSE)™ provided by Enea®, Nucleus RTOS™ provided by MentorGraphics®, Versatile Real-Time Executive (VRTX) provided by MentorGraphics®, ThreadX™ provided by Express Logic®, FreeRTOS, REX OSprovided by Qualcomm®, OKL4 provided by Open Kernel (OK) Labs®, or anyother suitable RTOS, such as those discussed herein.

Although not shown by FIG. 3 , in one embodiment, the baseband circuitry310 includes individual processing device(s) to operate one or morewireless communication protocols (e.g., a “multi-protocol basebandprocessor” or “protocol processing circuitry”) and individual processingdevice(s) to implement physical layer (PHY) functions. In thisembodiment, the protocol processing circuitry operates or implementsvarious protocol layers/entities of one or more wireless communicationprotocols. In a first example, the protocol processing circuitry mayoperate LTE protocol entities and/or 5G/NR protocol entities when theRFEMs 315 are cellular radiofrequency communication system, such asmillimeter wave (mmWave) communication circuitry or some other suitablecellular communication circuitry. In the first example, the protocolprocessing circuitry would operate MAC, RLC, PDCP, SDAP, RRC, and NASfunctions. In a second example, the protocol processing circuitry mayoperate one or more IEEE-based protocols when the RFEMs 315 are WiFicommunication system. In the second example, the protocol processingcircuitry would operate WiFi MAC and LLC functions. The protocolprocessing circuitry may include one or more memory structures (notshown) to store program code and data for operating the protocolfunctions, as well as one or more processing cores (not shown) toexecute the program code and perform various operations using the data.The protocol processing circuitry provides control functions for thebaseband circuitry 310 and/or RFEMs 315. The baseband circuitry 310 mayalso support radio communications for more than one wireless protocol.

Continuing with the aforementioned embodiment, the baseband circuitry310 includes individual processing device(s) to implement PHY includingHARQ functions, scrambling and/or descrambling, (en)coding and/ordecoding, layer mapping and/or de-mapping, modulation symbol mapping,received symbol and/or bit metric determination, multi-antenna portpre-coding and/or decoding which may include one or more of space-time,space-frequency or spatial coding, reference signal generation and/ordetection, preamble sequence generation and/or decoding, synchronizationsequence generation and/or detection, control channel signal blinddecoding, radio frequency shifting, and other related functions. etc.The modulation/demodulation functionality may include Fast-FourierTransform (FFT), precoding, or constellation mapping/demappingfunctionality. The (en)coding/decoding functionality may includeconvolution, tail-biting convolution, turbo, Viterbi, or Low DensityParity Check (LDPC) coding. Embodiments of modulation/demodulation andencoder/decoder functionality are not limited to these examples and mayinclude other suitable functionality in other embodiments.

User interface circuitry 350 may include one or more user interfacesdesigned to enable user interaction with the system 300 or peripheralcomponent interfaces designed to enable peripheral component interactionwith the system 300. User interfaces may include, but are not limitedto, one or more physical or virtual buttons (e.g., a reset button), oneor more indicators (e.g., light emitting diodes (LEDs)), a physicalkeyboard or keypad, a mouse, a touchpad, a touchscreen, speakers orother audio emitting devices, microphones, a printer, a scanner, aheadset, a display screen or display device, etc. Peripheral componentinterfaces may include, but are not limited to, a nonvolatile memoryport, a universal serial bus (USB) port, an audio jack, a power supplyinterface, etc.

The radio front end modules (RFEMs) 315 may comprise a millimeter wave(mmWave) RFEM and one or more sub-mmWave radio frequency integratedcircuits (RFICs). In some implementations, the one or more sub-mmWaveRFICs may be physically separated from the mmWave RFEM. The RFICs mayinclude connections to one or more antennas or antenna arrays, and theRFEM may be connected to multiple antennas. In alternativeimplementations, both mmWave and sub-mmWave radio functions may beimplemented in the same physical RFEM 315, which incorporates bothmmWave antennas and sub-mmWave. The antenna array comprises one or moreantenna elements, each of which is configured convert electrical signalsinto radio waves to travel through the air and to convert received radiowaves into electrical signals. For example, digital baseband signalsprovided by the baseband circuitry 310 is converted into analog RFsignals (e.g., modulated waveform) that will be amplified andtransmitted via the antenna elements of the antenna array including oneor more antenna elements (not shown). The antenna elements may beomnidirectional, direction, or a combination thereof. The antennaelements may be formed in a multitude of arranges as are known and/ordiscussed herein. The antenna array may comprise microstrip antennas orprinted antennas that are fabricated on the surface of one or moreprinted circuit boards. The antenna array may be formed in as a patch ofmetal foil (e.g., a patch antenna) in a variety of shapes, and may becoupled with the RF circuitry using metal transmission lines or thelike.

The memory circuitry 320 may include one or more of volatile memoryincluding dynamic random access memory (DRAM) and/or synchronous dynamicrandom access memory (SDRAM), and nonvolatile memory (NVM) includinghigh-speed electrically erasable memory (commonly referred to as Flashmemory), phase change random access memory (PRAM), magnetoresistiverandom access memory (MRAM), etc., and may incorporate thethree-dimensional (3D) cross-point (XPOINT) memories from Intel® andMicron®. Memory circuitry 320 may be implemented as one or more ofsolder down packaged integrated circuits, socketed memory modules andplug-in memory cards.

The memory circuitry 320 is configured to store computational logic (or“modules”) in the form of software, firmware, or hardware commands toimplement the techniques described herein. The computational logic ormodules may be developed using a suitable programming language ordevelopment tools, such as any programming language or development tooldiscussed herein. The computational logic may be employed to storeworking copies and/or permanent copies of programming instructions forthe operation of various components of appliance infrastructureequipment 300, an operating system of infrastructure equipment 300, oneor more applications, and/or for carrying out the embodiments discussedherein. The computational logic may be stored or loaded into memorycircuitry 320 as instructions for execution by the processors of theapplication circuitry 305 to provide or perform the functions describedherein. The various elements may be implemented by assemblerinstructions supported by processors of the application circuitry 305 orhigh-level languages that may be compiled into such instructions. Thepermanent copy of the programming instructions may be placed intopersistent storage devices of memory circuitry 320 in the factory duringmanufacture, or in the field through, for example, a distribution medium(not shown), through a communication interface (e.g., from adistribution server), and/or over-the-air (OTA).

In some embodiments, the infrastructure equipment 300 may be a NAN131-133 that is configured to collect data for the LPP services 200discussed herein. In these embodiments, the memory circuitry 320 maystore one or more applications and/or software components includingprogram code, instructions, modules, assemblies, packages, protocolstacks, software engine(s), firmware, etc., which when running on theinfrastructure equipment 300 (e.g., executed by application circuitry305), collect spatial-temporal data (see e.g., FIG. 6 infra), andprovides this information to one or more prediction layers 205 in theLPPS 200 via a suitable backhaul link via network controller circuitry335 and network interface connector 340. As discussed in more detailinfra, the spatial-temporal data such as operational parameters of thesystem 300, signal measurements, and/or other like data as discussedherein, may be accessed using suitable APIs, Application BinaryInterfaces (ABIs), middleware, drivers, configuration files, trustedapplication(s), etc., for accessing measurement data and/or other likeinformation from the baseband circuitry and/or from network functions inthe CN 142. For example, these APIs, drivers, etc., may accessmeasurement data of measurements directly measured by the infrastructureequipment 300, measurements collected by UEs 111, 121 duringminimization drive tests (MDTs), and/or measurement data collected byUEs 111, 121 and/or the infrastructure equipment 300 measurementsperformed by the UEs 111, 121 for other purposes, such as measurementstaken for cell selection, handovers, and/or the like. In anotherexample, one or more APIs may be used to collect network loadinformation from the CN 142 (or one or more NFs within the CN 142 or thelike). In some embodiments, these applications, components, plug-ins,firmware, etc., may also subscribe to the LPPS 200 to receive LPPnotifications or “hints” from the LPPS 200 (see e.g., FIGS. 13-19 ).

In other embodiments, the infrastructure equipment 300 may be a servercomputer system that is configured to operate one or more predictionlayers 225-1 to 225-N and/or the LPPS layer 202 of FIG. 2 . In theseembodiments, the memory circuitry 320 may store one or more applicationsand/or software components including program code, instructions,modules, assemblies, packages, protocol stacks, software engine(s),firmware, etc., which when running on the infrastructure equipment 300(e.g., executed by application circuitry 305), perform various functionsof the one or more prediction layers 225-1 to 225-N and/or the LPPSlayer 202, such as those discussed w.r.t FIGS. 6-19 infra.

The PMIC 325 may include voltage regulators, surge protectors, poweralarm detection circuitry, and one or more backup power sources such asa battery or capacitor. The power alarm detection circuitry may detectone or more of brown out (under-voltage) and surge (over-voltage)conditions. The power tee circuitry 330 may provide for electrical powerdrawn from a network cable to provide both power supply and dataconnectivity to the infrastructure equipment 300 using a single cable.

The network controller circuitry 335 provides connectivity to a networkusing a standard network interface protocol such as Ethernet, Ethernetover GRE Tunnels, Ethernet over Multiprotocol Label Switching (MPLS), orsome other suitable protocol, such as those discussed herein. Networkconnectivity may be provided to/from the infrastructure equipment 300via network interface connector 340 using a physical connection, whichmay be electrical (commonly referred to as a “copper interconnect”),optical, or wireless. The network controller circuitry 335 may includeone or more dedicated processors and/or FPGAs to communicate using oneor more of the aforementioned protocols. In some implementations, thenetwork controller circuitry 335 may include multiple controllers toprovide connectivity to other networks using the same or differentprotocols. In various embodiments, the network controller circuitry 335enables communication with associated equipment and/or with a backendsystem (e.g., server(s) 130 of FIG. 1 ), which may take place via asuitable gateway device.

The positioning circuitry 345 includes circuitry to receive and decodesignals transmitted/broadcasted by a positioning network of a globalnavigation satellite system (GNSS). Examples of navigation satelliteconstellations (or GNSS) include United States' Global PositioningSystem (GPS), Russia's Global Navigation System (GLONASS), the EuropeanUnion's Galileo system, China's BeiDou Navigation Satellite System, aregional navigation system or GNSS augmentation system (e.g., Navigationwith Indian Constellation (NAVIC), Japan's Quasi-Zenith Satellite System(QZSS), France's Doppler Orbitography and Radio-positioning Integratedby Satellite (DORIS), etc.), or the like. The positioning circuitry 345comprises various hardware elements (e.g., including hardware devicessuch as switches, filters, amplifiers, antenna elements, and the like tofacilitate OTA communications) to communicate with components of apositioning network, such as navigation satellite constellation nodes.In some embodiments, the positioning circuitry 345 may include aMicro-Technology for Positioning, Navigation, and Timing (Micro-PNT) ICthat uses a master timing clock to perform position tracking/estimationwithout GNSS assistance. The positioning circuitry 345 may also be partof, or interact with, the baseband circuitry 310 and/or RFEMs 315 tocommunicate with the nodes and components of the positioning network.The positioning circuitry 345 may also provide position data and/or timedata to the application circuitry 305, which may use the data tosynchronize operations with various other infrastructure equipment, orthe like.

The components shown by FIG. 3 may communicate with one another usinginterface circuitry 306 or interconnect (IX) 306, which may include anynumber of bus and/or interconnect (IX) technologies such as industrystandard architecture (ISA), extended ISA (EISA), inter-integratedcircuit (I²C), an serial peripheral interface (SPI), point-to-pointinterfaces, power management bus (PMBus), peripheral componentinterconnect (PCI), PCI express (PCIe), Intel® Ultra Path Interface(UPI), Intel® Accelerator Link (IAL), Common Application ProgrammingInterface (CAPI), Intel® QuickPath interconnect (QPI), Ultra PathInterconnect (UPI), Intel® Omni-Path Architecture (OPA) IX, RapidIO™system IXs, Cache Coherent Interconnect for Accelerators (CCIA), Gen-ZConsortium IXs, Open Coherent Accelerator Processor Interface (OpenCAPI)IX, a HyperTransport interconnect, and/or any number of other IXtechnologies. The IX technology may be a proprietary bus, for example,used in an SoC based system.

FIG. 4 depicts a block diagram for an example Multi-access EdgeComputing (MEC) system architecture 400. As mentioned previously, theedge compute nodes 136 of FIG. 1 may be implemented using MECtechnologies. MEC offers application developers and content providerscloud-computing capabilities and an Information Technology (IT) serviceenvironment at the edge of the network. This environment ischaracterized by ultra-low latency and high bandwidth as well asreal-time access to radio network information that can be leveraged byapplications. MEC technology permits to flexible and rapid deployment ofinnovative applications and services towards mobile subscribers,enterprises and vertical segments. In particular, the MEC system 400allows applications to, inter alia, exchange data, provide data toaggregation points, and access to data in databases which provide anoverview of the local situation derived from a multitude of sensors.

The illustrated logical connections between various entities of the MECarchitecture 400 may be access-agnostic and not dependent on aparticular deployment. MEC enables implementation of MEC applications(MEC Apps) 436-1 and 436-2 (collectively referred to as “MEC Apps 436”or the like) as software-only entities that run on top of aVirtualization Infrastructure (VI) 438-1 and 438-2 (collectivelyreferred to as “VI 438” or the like), which is located in or close tothe network edge. A MEC app 436 is an application that can beinstantiated on a MEC host 136 within the MEC system 400 and canpotentially provide or consume MEC services 437 a. The term “userapplication” in the context of MEC refers to an MEA 436 that isinstantiated in the MEC system 400 in response to a request from a user(e.g., UE 1111, 121) via a device application. FIG. 4 shows the generalentities involved, and these entities can be grouped into multi-accessedge system level 402, multi-access edge host level 401, and networklevel entities (not shown). The multi-access edge host level 401includes a MEC host 136-1 and MEC host 136-2 (which may be the same orsimilar to the MEC servers 136 discussed previously, and arecollectively referred to as “MEC host 136” or the like) and Multi-accessEdge (ME) management 430, which provide functionality to run MEC Apps436 within an operator network or a subset of an operator network. Themulti-access edge system level 402 includes multi-access edge systemlevel management 402, UE 420 (which may be the same or similar to theintermediate nodes 120 and/or endpoints 110 discussed herein), and thirdparty entities. The network level (not shown) includes various externalnetwork level entities, such as a 3GPP network (e.g., CN 142 of FIG. 1), a local area network (e.g., a LAN, WLAN, PAN, etc.), and an externalnetwork (e.g., CN 142 and/or cloud 144 of FIG. 1 ). The multi-accessedge host level 401 includes multi-access edge host level management andone or more MEC hosts 136. The multi-access edge host level managementmay include various components that handle the management of themulti-access edge specific functionality of a particular MEC platform437, MEC host 136, and the MEC Apps 436 to be run. The MEC host 136includes the MEC platform 437, MEC Apps 436, and VI 438.

The MEC system 400 includes three groups of reference points, including“Mp” reference points regarding the multi-access edge platformfunctionality; “Mm” reference points, which are management referencepoints; and “Mx” reference points, which connect MEC entities toexternal entities. The interfaces/reference points in the MEC system 400may include IP-based connections, and may be used to provideRepresentational State Transfer (REST or RESTful) services, and themessages conveyed using the reference points/interfaces may be in XML,HTML, JSON, or some other desired format, such as those discussedherein. A suitable Authentication, Authorization, and Accounting (AAA)protocol, such as the radius or diameter protocols, may also be used forcommunicating over the reference points/interfaces in other embodiments.

The MEC host 136 is an entity that contains an MEC platform 437 and VI438 which provides compute, storage, and network resources for thepurpose of running MEC Apps 436. Each of the VIs 438 includes arespective data plane (DP) 439 (including DP 439-1 and 439-2) thatexecutes respective traffic rules 437-1 b and 437-2 b (collectivelyreferred to as “traffic rules 437 b”) received by the MEC platform 437,and routes the traffic among applications (e.g., MEC Apps 436), MECservices 437-la and 437-2 a (collectively referred to as “MEC services437 a”), DNS server/proxy (see e.g., via DNS handling entities 437-1 cand 437-2 c), 3GPP network, local networks, and external networks. TheMEC DP 438 a may be connected with the (R)AN nodes 131 and CN 142 ofFIG. 1 , and/or may be connected with the AP 133 of FIG. 1 via a widernetwork, such as the internet, an enterprise network, or the like. Theother entities depicted and/or discussed herein may be the same orsimilar as those discussed with regard to FIG. 1 .

The MEC platforms 437-1 and 437-2 (collectively referred to as “MECplatform 437” or the like) within a MEC host 136 may be a collection ofessential functionality required to run MEC Apps 436 on a particular VI438 and enable them to provide and consume MEC services 437 a, and thatcan provide itself a number of MEC services 437 a. The MEC platform 437can also provide various services and/or functions, such as offering anenvironment where the MEC Apps 436 can discover, advertise, consume andoffer MEC services 437 a (discussed infra), including MEC services 437 aavailable via other platforms when supported. The MEC platform 437 maybe able to allow authorized MEC Apps 436 to communicate with third partyservers located in external networks. The MEC platform 437 may receivetraffic rules from the MEC platform manager 431, applications, orservices, and instruct the data plane accordingly (see e.g., TrafficRules Control 437 b). The MEC platform 437 may send instructions to theDP 438 within the VI 438 via the Mp2 reference point. The Mp2 referencepoint between the MEC platform 437 and the DP 438 of the VI 438 may beused to instruct the DP 438 on how to route traffic among applications,networks, services, etc. In some implementations, the MEC platform 437may translate tokens representing UEs XP01 in the traffic rules intospecific IP addresses. The MEC platform 437 also receives DNS recordsfrom the MEC platform manager 431 and configures a DNS proxy/serveraccordingly. The MEC platform 437 hosts MEC services 437 a including themulti-access edge services discussed infra, and provide access topersistent storage and time of day information. Furthermore, the MECplatform 437 may communicate with other MEC platforms 437 of other MECservers 136 via the Mp3 reference point.

The VI 438 may represent the totality of all hardware and softwarecomponents which build up the environment in which MEC Apps 436 and/orMEC platform 437 are deployed, managed and executed. The VI 438 may spanacross several locations, and the network providing connectivity betweenthese locations is regarded to be part of the VI 438. The physicalhardware resources of the VI 438 includes computing, storage and networkresources that provide processing, storage and connectivity to MEC Apps436 and/or MEC platform 437 through a virtualization layer (e.g., ahypervisor, VM monitor (VMM), or the like). The virtualization layer mayabstract and/or logically partition the physical hardware resources ofthe MEC server 136 as a hardware abstraction layer. The virtualizationlayer may also enable the software that implements the MEC Apps 436and/or MEC platform 437 to use the underlying VI 438, and may providevirtualized resources to the MEC Apps 436 and/or MEC platform 437, sothat the MEC Apps 436 and/or MEC platform 437 can be executed.

The MEC Apps 436 are applications that can be instantiated on a MEC host136 within the MEC system 400 and can potentially provide or consume MECservices 437 a. The term “MEC service” refers to a service provided viaa MEC platform 437 either by the MEC platform 437 itself or by a MEC App436. MEC Apps 436 may run as VM on top of the VI 438 provided by the MECserver 136, and can interact with the MEC platform 437 to consume andprovide the MEC services 437 a. The MEC Apps 436 are instantiated on theVI 438 of the MEC server 136 based on configuration or requestsvalidated by the ME management 430. The MEC Apps 436 can also interactwith the MEC platform 437 to perform certain support procedures relatedto the lifecycle of the MEC Apps 436, such as indicating availability,preparing relocation of user state, etc. The MEC Apps 436 may have acertain number of rules and requirements associated to them, such asrequired resources, maximum latency, required or useful services, etc.These requirements may be validated by the ME management 430, and can beassigned to default values if missing. MEC services 437-la and 437-2 a(collectively referred to as “MEC services “437 a” or the like) areservices provided and/or consumed either by the MEC platform 437 and/orMEC Apps 436. The service consumers (e.g., MEC Apps 436 and MEC platform437) may communicate with particular MEC services 437 a over individualAPIs (including MEC LPP API 451-1, 451-2 and various APIs 453-1, 453-2in FIG. 4 ). When provided by an application, a MEC service 437 a can beregistered in a list of services in the service registries 437-1 d and437-2 d (collectively referred to as “service registry 437 d” or thelike) to a respective the MEC platform 437 over the Mp1 reference point.Additionally, the MEC Apps 436 can subscribe to one or more services 437a for which it is authorized over the Mp1 reference point. In variousembodiments, one or more MEC Apps 436 are configured to collect data forthe LPP services discussed herein (e.g., LPPS 200 of FIG. 2 ). In theseembodiments, the MEC platform 437 may operate these MEC Apps 436 toperform the various functionalities of the LPP layer 202 (or LPP engine)and/or one or more prediction layers 225 to 225-N of FIG. 2 , and/orperform the various functionalities of the embodiments discussed infraw.r.t FIG. 6-19 .

The MEC system 400 may support a feature called UserApps. When the MECsystem 400 supports the feature UserApps, the ME management 430 maysupport the instantiation of MEC Apps 436 (or user applications) onmultiple MEC hosts 136 following a single instantiation request, andwhen required by the operator in response to a request by the user. Theapplication instance may need to fulfill a number of potentialconstraints predefined for the application 405. Once instantiated,connectivity may be established between the UE 420 and the applicationinstance. Potential constraints may include latency, location, computeresources, storage resources, network capability, security conditions,and the like. As part of the user application (or MEC app 436)instantiation, the MEC system 400 will create an associated applicationcontext that the MEC system 400 maintains for the lifetime of the userapplication (or MEC app 436). The application context is a set ofreference data about an application instance that is used to identifyit, enable lifecycle management operations and associate it with itsdevice application, The term “user context” in the context of MEC refersto application-specific runtime data maintained by a MEC app 436, whichis associated with a user of that application. The application contextcontains information specific to the application instance such as itsunique identifier within the MEC system 400 and the address (e.g., URIor the like) provided for clients (e.g., UE 420) that are external tothe MEC system 400 to interact with the user application.

When the MEC system 400 supports the feature UserApps, the system 400may, in response to a request by a user, support the establishment ofconnectivity between the UE 420 and an instance of a specific MEC App436 fulfilling the requirements of the MEC App 436 regarding the UE 420.If no instance of the MEC App 436 fulfilling these requirements iscurrently running, the multi-access edge system management may create anew instance of the application 405 on a MEC host 136 that fulfils therequirements of the application 405. Once instantiated, connectivity isestablished between the UE 420 and the new MEC App 436 instance.Requirements of the application can include latency, location, computeresources, storage resources, network capability, security conditions,and the like. When the MEC system 400 supports the UserApps feature, thesystem 400 may support the on-boarding of MEC Apps 436 during theexecution of an instantiation request, may allow the establishment ofconnectivity between the UE 420 and a specific instance of an MEC App436, may support the capability to terminate the MEC App 436 instancewhen no UE 420 is connected to it anymore, and may support thetermination of the MEC App 436 running on multiple MEC servers 136following a single termination request.

As shown by FIG. 4 , the Mp1 reference point is between the MEC platform437 and the MEC Apps 436. The Mp1 reference point may provide serviceregistration 437 d, service discovery, and communication support forvarious services, such as the MEC services 437-la provided by MEC host136-1 and MEC services 437-2 a provided by MEC host 136-2 (collectivelyreferred to as “MEC services 437 a” or the like). In addition, the Mp1interface may provide application availability, session state relocationsupport procedures, traffic rules and DNS rules activation, access topersistent storage and time of day information, and/or the like. The Mp1reference point may be used for consuming and providing service specificfunctionality.

Examples of MEC services 437 a include Radio Network Information Service(RNIS), location services, and bandwidth management services. The RNIS,when available, provides authorized MEC Apps 436 with radio networkrelated information, and expose appropriate up-to-date radio networkinformation to the MEC Apps 436. The radio network information (RNI) mayinclude, inter alia, radio network conditions, measurement andstatistics information related to the user plane, information related toUEs 420 served by the radio node(s) associated with the MEC host 136(e.g., UE context and radio access bearers), changes on informationrelated to UEs 420 served by the radio node(s) associated with the MEChost 136, and/or the like. The RNI may be provided at the relevantgranularity (e.g., per UE 420, per cell, per period of time).

The service consumers (e.g., MEC Apps 436 and MEC platform 437) maycommunicate with the RNIS over an RNI API 453 to obtain contextualinformation from a corresponding RAN. RNI may be provided to the serviceconsumers via an access node (e.g., (R)AN nodes 131, 132, or AP 133 ofFIG. 1 ). The RNI API 453 may support both query and subscription (e.g.,a pub/sub) based mechanisms that are used over a Representational StateTransfer (RESTful) API 453 or over a message broker of the MEC platform437 (not shown by FIG. 4 ). A MEC App 436 may query information on amessage broker via a transport information query procedure, wherein thetransport information may be pre-provisioned to the MEC App 436 via asuitable configuration mechanism. The various messages communicated viathe RNI API 453 may be in XML, JSON, Protobuf, or some other suitableformat.

The RNI may be used by MEC Apps 436 and MEC platform 437 to optimize theexisting services and to provide new types of services that are based onup to date information on radio conditions. As an example, a MEC App 436may use RNI to optimize current services such as video throughputguidance. In throughput guidance, a radio analytics MEC App 436 may useMEC services to provide a backend video server with a near real-timeindication on the throughput estimated to be available at the radiodownlink interface in a next time instant. The throughput guidance radioanalytics application 436 computes throughput guidance based on therequired radio network information it obtains from a multi-access edgeservice running on the MEC server 136. RNI may be also used by the MECplatform 437 to optimize the mobility procedures required to supportservice continuity, such as when a certain MEC App 436 requests a singlepiece of information using a simple request-response model (e.g., usingRESTful mechanisms) while other MEC Apps 436 subscribe to multipledifferent notifications regarding information changes (e.g., using apub/sub mechanism and/or message broker mechanisms).

The location services (LS), when available, may provide authorized MECApps 436 with location-related information, and expose such informationto the MEC Apps 436. With location related information, the MEC platform437 or one or more MEC Apps 436 perform active device location tracking,location-based service recommendations, and/or other like services. TheLS supports the location retrieval mechanism, e.g., the location isreported only once for each location information request. The LSsupports a location subscribe mechanism, for example, the location isable to be reported multiple times for each location request,periodically or based on specific events, such as location change. Thelocation information may include, inter alia, the location of specificUEs 420 currently served by the radio node(s) associated with the MECserver 136, information about the location of all UEs 420 currentlyserved by the radio node(s) associated with the MEC server 136,information about the location of a certain category of UEs 420currently served by the radio node(s) associated with the MEC server136, a list of UEs 420 in a particular location, information about thelocation of all radio nodes currently associated with the MEC server136, and/or the like. The location information may be in the form of ageolocation, a Global Navigation Satellite Service (GNSS) coordinate, aCell identity (ID), and/or the like. The LS is accessible through theAPI defined in the Open Mobile Alliance (OMA) specification “RESTfulNetwork API for Zonal Presence”OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C. The Zonal Presenceservice utilizes the concept of “zone”, where a zone lends itself to beused to group all radio nodes that are associated to a MEC host or MECserver 136, or a subset thereof, according to a desired deployment. Inthis regard, the OMA Zonal Presence API 453 provides means for MEC Apps436 to retrieve information about a zone, the access points associatedto the zones and the users that are connected to the access points. Inaddition, the OMA Zonal Presence API 453, allows authorized applicationto subscribe to a notification mechanism, reporting about useractivities within a zone. In various embodiments, a MEC server 136 mayaccess location information or zonal presence information of individualUEs 420 using the OMA Zonal Presence API 453 to identify the relativelocation or positions of the UEs 420.

The bandwidth management services (BWMS) provides for the allocation ofbandwidth (BW) to certain traffic routed to and from MEC Apps 436, andspecify static/dynamic up/down BW resources, including BW size and BWpriority. MEC Apps 436 may use the BWMS to update/receive BW informationto/from the MEC platform 437. In some embodiments, different MEC Apps436 running in parallel on the same MEC server 136 may be allocatedspecific static, dynamic up/down BW resources, including BW size and BWpriority. The BWMS includes a BW management (BWM) API 453 to allowedregistered applications to statically and/or dynamically register forspecific BW allocations per session/application. The BWM API 453includes HTTP protocol bindings for BWM functionality using RESTfulservices or some other suitable API mechanism.

Referring back to FIG. 4 , multi-access edge management comprisesmulti-access edge system level management and the multi-access edge hostlevel management 430. The ME management 430 comprises the MEC platformmanager 431 and the VI manager (VIM) 432, and handles the management ofMEC-specific functionality of a particular MEC server 136 and theapplications running on it. In some implementations, some or all of themulti-access edge management components may be implemented by one ormore servers located in one or more data centers, and may usevirtualization infrastructure that is connected with Network FunctionsVirtualization (NFV) infrastructure used to virtualize core networkelements, or using the same hardware as the NFV infrastructure.

The MEC platform manager 431 is responsible for managing the life cycleof applications including informing the multi-access edge orchestrator(MEC-O) 421 of relevant application related events. The MEC platformmanager 431 may also provide MEP element management functions 431 a tothe MEC platform 437, manage MEC App rules and requirements 431 bincluding service authorizations, traffic rules, DNS configuration andresolving conflicts, and manage MEC App 436 lifecycles (MEALC mgmt 431c). The MEC platform manager 431 may also receive virtualized resourcesfault reports and performance measurements from the VIM 432 for furtherprocessing. The Mm5 reference point between the MEC platform manager 431and the MEC platform 437 is used to perform platform configuration,configuration of the MEPE mgmt 431 a, the MERR mgmt 431 b, the MEALCmgmt 431 c, management of application relocation, etc.

The VIM 432 may be an entity that allocates, manages and releasesvirtualized (compute, storage and networking) resources of the VI 438,and prepares the VI 438 to run a software image. To do so, the VIM 432may communicate with the VI 438 over the Mm7 reference point between theVIM 432 and the VI 438. Preparing the VI 438 may include configuring theVI 438, and receiving/storing the software image. When supported, theVIM 432 may provide rapid provisioning of applications, such asdescribed in “Openstack++ for Cloudlet Deployments”, available athttp://reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf. TheVIM 432 may also collect and report performance and fault informationabout the virtualized resources, and perform application relocation whensupported. For application relocation from/to external cloudenvironments, the VIM 432 may interact with an external cloud manager toperform the application relocation, for example using the mechanismdescribed in “Adaptive VM Handoff Across Cloudlets”, and/or possiblythrough a proxy. Furthermore, the VIM 432 may communicate with the MECplatform manager 431 via the Mm6 reference point, which may be used tomanage virtualized resources, for example, to realize the applicationlifecycle management. Moreover, the VIM 432 may communicate with theMEC-O 421 via the Mm4 reference point, which may be used to managevirtualized resources of the MEC server 136, and to manage applicationimages. Managing the virtualized resources may include trackingavailable resource capacity, etc.

The multi-access edge system level management includes the MEC-O 421 asa core component, which has an overview of the complete MEC system 400.The MEC-O 421 may maintain an overall view of the MEC system 400 basedon deployed multi-access edge hosts 901, available resources, availableMEC services 437 a, and topology. The Mm3 reference point between theMEC-O 421 and the MEC platform manager 431 may be used for themanagement of the application lifecycle, application rules andrequirements and keeping track of available MEC services 437 a. TheMEC-O 421 may communicate with the user application lifecycle managementproxy (UALMP) 425 via the Mm9 reference point in order to manage MECApps 436 requested by UE application 405.

The MEC-O 421 may also be responsible for on-boarding of applicationpackages, including checking the integrity and authenticity of thepackages, validating application rules and requirements and if necessaryadjusting them to comply with operator policies, keeping a record ofon-boarded packages, and preparing the VIM(s) 402 to handle theapplications. The MEC-O 421 may select appropriate MEC host(s) 901 forapplication instantiation based on constraints, such as latency,available resources, and available services. The MEC-O 421 may alsotrigger application instantiation and termination, as well as triggerapplication relocation as needed and when supported.

The Operations Support System (OSS) 422 refers to the OSS of an operatorthat receives requests via the Customer Facing Service (CFS) portal 406(and over the Mx1 reference point) and from UE applications 405 forinstantiation or termination of MEC Apps 436, and decides on thegranting of these requests. The CFS portal 406 (and the Mx1 interface)may be used by third-parties to request the MEC system 400 to runapplications 406 in the MEC system 400. Granted requests may beforwarded to the MEC-O 421 for further processing. When supported, theOSS 422 also receives requests from UE applications 405 for relocatingapplications between external clouds and the MEC system 400. The Mm2reference point between the OSS 422 and the MEC platform manager 431 isused for the MEC platform manager 431 configuration, fault andperformance management. The Mm1 reference point between the MEC-O 421and the OSS 422 is used for triggering the instantiation and thetermination of multi-access edge applications 436 in the MEC system 400.

The UE app(s) 405 (also referred to as “device applications” or thelike) is one or more applications running in a device, computing system,etc. (e.g., UE 420), that has the capability to interact with the MECsystem 900 via the user application lifecycle management proxy 425. TheUE app(s) 405 may be, include, or interact with one or more clientapplications, which in the context of MEC, is application softwarerunning on a device, computing system, etc. that utilizes functionalityprovided by one or more specific MEC application(s) 436. The userapplication lifecycle management proxy (“user app LCM proxy”) 425 mayauthorize requests from UE applications 405 in the UE and interacts withthe OSS 422 and the MEC-O 421 for further processing of these requests.The term “lifecycle management,” in the context of MEC, refers to a setof functions required to manage the instantiation, maintenance andtermination of a MEC application 436 instance. The user app LCM proxy425 may interact with the OSS 422 via the Mm8 reference point, and isused to handle UE applications 405 requests for running applications inthe MEC system 400. A user application 405 may be an MEC App 436 that isinstantiated in the MEC system 400 in response to a request of a uservia an application running in the UE 420 (e.g., UE application 405). Theuser app LCM proxy 425 allows UE applications 405 to requeston-boarding, instantiation, termination of user applications and whensupported, relocation of user applications in and out of the MEC system400. It also allows informing the UE applications 405 about the state ofthe user applications 405. The user app LCM proxy 425 is only accessiblefrom within the mobile network, and may only be available when supportedby the MEC system 400. A UE application 405 may use the Mx2 referencepoint between the user app LCM proxy 425 and the UE application 405 torequest the MEC system 400 to run an application in the MEC system 400,or to move an application in or out of the MEC system 400. The Mx2reference point may only be accessible within the mobile network and mayonly be available when supported by the multi-access edge system.

In order to run an MEC App 436 in the MEC system 400, the MEC-O 421receives requests triggered by the OSS 422, a third-party, or a UEapplication 405. In response to receipt of such requests, the MEC-O 421selects a MEC server 136 to host the MEC App 436 for computationaloffloading. These requests may include information about the applicationto be run, and possibly other information, such as the location wherethe application needs to be active, other application rules andrequirements, as well as the location of the application image if it isnot yet on-boarded in the MEC system 400.

The MEC-O 421 selects one or more MEC servers 136 for computationalintensive tasks. The selected one or more MEC servers 136 may offloadcomputational tasks of a UE application 405 based on various operationalparameters, such as network capabilities and conditions, computationalcapabilities and conditions, application requirements, and/or other likeoperational parameters. The application requirements may be rules andrequirements associated to/with one or more MEC Apps 436, such asdeployment model of the application (e.g., whether it is one instanceper user, one instance per host, one instance on each host, etc.);required virtualized resources (e.g., compute, storage, networkresources, including specific hardware support); latency requirements(e.g., maximum latency, how strict the latency constraints are, latencyfairness between users); requirements on location; multi-access edgeservices that are required and/or useful for the MEC Apps 436 to be ableto run; multi-access edge services that the MEC Apps 436 can takeadvantage of, if available; connectivity or mobilitysupport/requirements (e.g., application state relocation, applicationinstance relocation); required multi-access edge features, such as VMrelocation support or UE identity; required network connectivity (e.g.,connectivity to applications within the multi-access edge system,connectivity to local networks, or to the Internet); information on theoperator's MEC system deployment or mobile network deployment (e.g.,topology, cost); requirements on access to user traffic; requirements onpersistent storage; traffic rules 437 b; DNS rules 437 c; etc.

The MEC-O 421 considers the requirements and information listed aboveand information on the resources currently available in the MEC system400 to select one or several MEC servers 136 within the MEC system 400to host MEC Apps 436 and/or for computational offloading. After one ormore MEC servers 136 are selected, the MEC-O 421 requests the selectedMEC host(s) 136 to instantiate the application(s) or application tasks.The actual algorithm used to select the MEC servers 136 depends on theimplementation, configuration, and/or operator deployment. In variousembodiments, the selection algorithm may be based on the task offloadingembodiments discussed herein, for example, by taking into accountnetwork, computational, and energy consumption requirements forperforming tasks of application tasks, as well as networkfunctionalities, processing, and offloading coding/encodings, ordifferentiating traffic between various RATs. Under certaincircumstances (e.g., UE mobility events resulting in increased latency,load balancing decisions, etc.), and if supported, the MEC-O 421 maydecide to select one or more new MEC servers 136 to act as a masternode, and initiates the transfer of an application instance orapplication-related state information from the one or more source MECservers 136 to the one or more target MEC servers 136.

As mentioned previously, the MEC system architecture 400 providessupport for applications. In the context of FIG. 4 , the UE app 405 isan application instance running on a UE 420, which may subscribe to LPPservices/notifications from the LPPS 200 and/or request and receive LPPservices to/from the system. Additionally, the UE app 405 is anapplication instance running on a UE 420, which may be used by the LPPS200 to collect real-time and spatio-historical data from the UE 420 (orfrom components therein). These application instances obtain orotherwise interact with a LPP service via MEC LPP API 451 a and 451 b(collectively referred to as “MEC LPP API 451”). [[[MEC hosts 136 areco-located with edge infrastructure (e.g., NANs 131, 132, and 133 ofFIG. 1 ) and communicate with each other through the Mp3 interface.]]]

The LPP Information Services (LPP-IS) 452-1 and 452-2 (collectivelyreferred to as “MEC LPP-IS 452”) permits information exposure pertinentto the support of link quality/performance prediction use cases to MECapp 436 instances. The LPP-IS 452 may be produced by the MEC platform437 or by the MEC Apps 436. In the framework of LPPS 200, the UE 420 ishosting an LPP client application (see e.g., LPP App 620 of FIG. 6 ),and is connected to a certain MEC host 136 and a related MEC App 436operating within that MEC host 136. In presence of multiple MEC hosts136, the LPP-IS 452 permits exposure of LPP information between MEC Apps436 running on different MEC hosts 136, and exposure of LPP informationwith remote systems/services via the LPP API 451. The remotesystems/services may be remote application server instances (e.g.,server(s) 150 of FIG. 1 ), which can be located outside the MEC system135 (e.g., private clouds owned by the operator or by the OEM such ascloud 144) and may access the LPP notifications via the LPP API 451.

LPP-IS 452 also permits a single network operator to offer a LPPservice(s) over a region that may span different countries and involvemultiple networks, MEC systems 400, and MEC app 436 providers. For thatpurpose, the MEC LPP-IS 452 includes the following functionalities.

The MEC platform 437 can include a MEC LPP API 451 and provide MECLPP-IS 452, which can include the following functionalities: (a)gathering of relevant UE information from an access network for purposesof performing UE authorization for LPP services (e.g., obtaining a listof LPP authorized UEs 420, obtaining relevant information about theauthorization based on UE subscription information/data, and obtainingUE configuration parameters such as a common set of radio linkconfiguration parameters and/or UE capabilities, if available); (b)gathering of relevant radio link and/or backhaul link information fromthe access network for determining and providing LPPs to the UEs 420;(c) exposure of the information obtained in (a)-(b) to MEC apps 436 inthe same MEC host 136 or MEC apps 436 in other MEC hosts 136 via the MECLPP API 451; (d) for core network based implementations, enablement ofMEC apps 436 to communicate securely with the LPP-related core networkfunctions (e.g., enabling communication between the MEC host and an “LPPcontrol function” in the core network); (e) enablement of MEC apps 436in different MEC systems 400 to communicate securely with each other;and (d) gathering and processing information available in other MEChosts 136 via one or more other MEC APIs 453 (e.g., gathering andprocessing information obtained from the RNI API, LS API, BWM API, aWLAN API, and/or other APIs that may be implemented within the MECplatform 437 such as those discussed herein) in order to predict radionetwork congestion, BW measurements/resources, UE 420location(s)/mobility, and provide suitable notifications (e.g., LPPnotifications) to the UE 420.

From that perspective, the LPP-IS 452 is relevant to Mp1 and Mp3reference points in the MEC architecture 400. In particular, therelevant information is exposed to MEC apps 436 via the Mp1 referencepoint, and the Mp3 reference point may enable the possibility totransfer this information between different MEC platforms 437. The MECLPP API 451 provides information to MEC apps 436 in a standardized way,which provides interoperability in multi-vendor scenarios. Nevertheless,MEC apps 436 may communicate in a direct way (e.g., without the use ofMEC platform 437). Inter-system communication may be realized betweenMEC Orchestrators 421. As an alternative, or, in addition to that,possible Mp3 enhancements (or new reference points between MEC systems400) may be defined.

Additionally or alternatively, the MEC host 136-2 in FIG. 4 can alsoimplement a MEC LPP API 451-2, which can provide an interface to one ormore of the apps instantiated within MEC host 2, such as MEC App 436-2b. In this regard, MEC host 136-1 and MEC host 136-2 can communicatewith each other via the Mp3 interface as well as the MEC LPP APIs 451-1,451-2. Additionally, one or more of the MEC apps 436-1 instantiatedwithin MEC host 136-1 can communicate with one or more of the MEC apps436-2 instantiated within MEC host 136-2 via the MEC LPP APIs 451-1,451-2 as well as the Mp3 interface between the MEC host 136-1 and MEChost 136-2.

Additionally or alternatively, each of the MEC hosts 136 can beowned/managed by a different mobile services operator (while it can beoperated directly by a MEC vendor or a third party). In some aspects,MEC apps 436 instantiated on MEC host 136-1 and MEC host 136-2 can beused to provide LPP-related services, and can be operated by the mobileservices operator, by a MEC vendor, or by a third party (e.g., OEM, orOEM supplier, or system integrator).

Additionally or alternatively, the MEC LPP APIs 451 can be provided as ageneral middleware service, providing information gathered from UEs 420and other network elements (e.g., NANs 131, 132, and/or 133 of FIG. 1 ),and exposed as a service within the MEC hosts 136 (e.g., as a RESTfulAPI) for the higher layers (e.g., the MEC apps 436 instantiated withinthe MEC hosts 136). In some aspects, the MEC LPP APIs 451 can beconfigured to gather information and data from various sensors. In thisregard, the deployment of the MEC LPP APIs 451 is ensuring continuity ofthe service across different mobile networks, for the same OEM (e.g., UEmanufacturer) and/or mobile network operator (MNO).

Additionally or alternatively, MEC apps 436 can be configured to hostand/or store LPP-related data and/or configuration parameters, such ascollected measurement data, UE operational/performance data (e.g.,application usage statistics, processor and/or memory utilization,and/or other like data such as those disused herein), UE capabilityinformation, and/or the like. The availability of this LPP-related dataand/or configuration parameters also in absence of network coverage isensured by the usage of an Mp3 interface (or another type of interface)between the MEC hosts 136.

Additionally or alternatively, MEC apps 436 can be configured to hostone or more prediction layers as discussed herein, such as a datacollection layer (or UE feedback layer), cell load layer (or cell modellayer), an intra-cell layer, a cell mobility layer (or cell transitionlayer), a geoposition layer (or geographical position layer), a networktopology layer, and/or other like prediction layers. The variousprediction layers may provide respective predicted performance metricsin absence of network coverage by the usage of an Mp3 interface (oranother type of interface) between the MEC hosts 136.

In any of the aforementioned embodiments, MEC app 436-1 can beconfigured to connect to MEC host 136-2 (through MEC LPP API 451-2 inMEC host 2), and MEC app 436-2 can be configured to connect to MEC host136-1 (through V2X MEC API 451-1 in MEC host 1). In case of amulti-operator architecture, multiple MEC hosts 136 can be configured tocommunicate with each other via the MEC LPP APIs 451 and synchronize inorder to transfer the relevant LPP-related data (e.g., real-time dataand/or spatio-historical data) and/or predicted performance metrics sothat they can be available across the multi-operator architecture inabsence of network coverage or during network infrastructure/equipmentfailures. In this way, the LPP service (e.g., LPPS 200 of FIG. 2 ) canhave access to the LPP-related data and/or the predicted performancemetrics even when the UEs 420 are not in network coverage or whenfailures or overload situations occur at different parts of the network.

One or more MEC apps 436 within a MEC host 136 can be instantiated toperform functionalities of an LPP engine (e.g., LPP layer 202 of FIG. 2), which may provide the LPP-IS 452. Additionally, MEC hosts 136 can useMEC LPP APIs 451 to perform various LPP-IS 452 functions. In particular,these one or more MEC apps 436 can be instantiated within a MEC host 136to perform various aspects of the LPP embodiments discussed herein, aswell as the following functionalities: obtaining LPP subscriptioninformation for UE 420; determining whether the UE 420 is authorized toobtain LPP notifications, which may or may not be in response to arequest for LPP services; communicating LPP-related data and/orconfiguration parameters; and so forth.

FIG. 5 illustrates an example of a platform 500 (also referred to as“system 500,” “device 500,” “appliance 500,” or the like). The platform500 may be suitable for use as intermediate nodes 120 and/or endpoints110 of FIG. 1 , and/or any other element/device discussed herein withregard any other figure shown and described herein. Platform 500 mayalso be implemented in or as a server computer system or some otherelement, device, or system discussed herein. The platform 500 mayinclude any combinations of the components shown in the example. Thecomponents of platform 500 may be implemented as integrated circuits(ICs), portions thereof, discrete electronic devices, or other modules,logic, hardware, software, firmware, or a combination thereof adapted inthe computer platform 500, or as components otherwise incorporatedwithin a chassis of a larger system. The example of FIG. 5 is intendedto show a high level view of components of the computer platform 500.However, some of the components shown may be omitted, additionalcomponents may be present, and different arrangement of the componentsshown may occur in other implementations.

The platform 500 includes processor circuitry 502. The processorcircuitry 502 includes circuitry such as, but not limited to one or moreprocessor cores and one or more of cache memory, low drop-out voltageregulators (LDOs), interrupt controllers, serial interfaces such asserial peripheral interface (SPI), inter-integrated circuit (I²C) oruniversal programmable serial interface circuit, real time clock (RTC),timer-counters including interval and watchdog timers, general purposeinput-output (10), memory card controllers such as securedigital/multi-media card (SD/MMC) or similar, universal serial bus (USB)interfaces, mobile industry processor interface (MIPI) interfaces andJoint Test Access Group (JTAG) test access ports. In someimplementations, the processor circuitry 502 may include one or morehardware accelerators, which may be microprocessors, programmableprocessing devices (e.g., FPGA, ASIC, etc.), or the like. The one ormore hardware accelerators may include, for example, computer vision,machine learning, and/or deep learning accelerators. In someimplementations, the processor circuitry 502 may include on-chip memorycircuitry, which may include any suitable volatile and/or non-volatilememory, such as DRAM, SRAM, EPROM, EEPROM, Flash memory, solid-statememory, and/or any other type of memory device technology, such as thosediscussed herein.

The processor(s) of processor circuitry 502 may include, for example,one or more processor cores (CPUs), one or more application processors,one or more graphics processing units (GPUs), one or more reducedinstruction set computing (RISC) processors, one or more Acorn RISCMachine (ARM) processors, one or more complex instruction set computing(CISC) processors, one or more digital signal processors (DSP), one ormore FPGAs, one or more PLDs, one or more ASICs, one or more basebandprocessors, one or more radio-frequency integrated circuits (RFIC), oneor more microprocessors or controllers, or any suitable combinationthereof. The processors (or cores) of the processor circuitry 502 may becoupled with or may include memory/storage and may be configured toexecute instructions stored in the memory/storage to enable variousapplications or operating systems to run on the platform 500. In theseembodiments, the processors (or cores) of the processor circuitry 502 isconfigured to operate application software to provide a specific serviceto a user of the platform 500. In some embodiments, the processorcircuitry 502 may be a special-purpose processor/controller to operateaccording to the various embodiments herein.

As examples, the processor circuitry 502 may include an Intel®Architecture Core™ based processor, such as a Quark™, an Atom™, an i3,an i5, an i7, an i9, or an MCU-class processor, Pentium® processor(s),Xeon® processor(s), or another such processor available from Intel®Corporation, Santa Clara, California. However, any number otherprocessors may be used, such as one or more of Advanced Micro Devices(AMD) Zen® Core Architecture, such as Ryzen® or EPYC® processor(s),Accelerated Processing Units (APUs), MxGPUs, Epyc® processor(s), or thelike; A5-A12 and/or S1-S4 processor(s) from Apple® Inc., Snapdragon™ orCentrig™ processor(s) from Qualcomm® Technologies, Inc., TexasInstruments, Inc.® Open Multimedia Applications Platform (OMAP)™processor(s); a MIPS-based design from MIPS Technologies, Inc. such asMIPS Warrior M-class, Warrior I-class, and Warrior P-class processors;an ARM-based design licensed from ARM Holdings, Ltd., such as the ARMCortex-A, Cortex-R, and Cortex-M family of processors; the ThunderX2®provided by Cavium™, Inc.; or the like. In some implementations, theprocessor circuitry 502 may be a part of a system on a chip (SoC),System-in-Package (SiP), a multi-chip package (MCP), and/or the like, inwhich the processor circuitry 502 and other components are formed into asingle integrated circuit, or a single package, such as the Edison™ orGalileo™ SoC boards from Intel® Corporation. Other examples of theprocessor circuitry 502 are mentioned elsewhere in the presentdisclosure.

Additionally or alternatively, processor circuitry 502 may includecircuitry such as, but not limited to, one or more FPDs such as FPGAsand the like; PLDs such as CPLDs, HCPLDs, and the like; ASICs such asstructured ASICs and the like; PSoCs; and the like. In such embodiments,the circuitry of processor circuitry 502 may comprise logic blocks orlogic fabric including and other interconnected resources that may beprogrammed to perform various functions, such as the procedures,methods, functions, etc. of the various embodiments discussed herein. Insuch embodiments, the circuitry of processor circuitry 502 may includememory cells (e.g., EPROM, EEPROM, flash memory, static memory (e.g.,SRAM, anti-fuses, etc.) used to store logic blocks, logic fabric, data,etc. in LUTs and the like.

The processor circuitry 502 may communicate with system memory circuitry504 over an interconnect 506 (e.g., a bus). Any number of memory devicesmay be used to provide for a given amount of system memory. As examples,the memory circuitry 504 may be random access memory (RAM) in accordancewith a Joint Electron Devices Engineering Council (JEDEC) design such asthe DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, orLPDDR4), dynamic RAM (DRAM), and/or synchronous DRAM (SDRAM)). Thememory circuitry 504 may also include nonvolatile memory (NVM) such ashigh-speed electrically erasable memory (commonly referred to as “flashmemory”), phase change RAM (PRAM), resistive memory such asmagnetoresistive random access memory (MRAM), etc., and may incorporatethree-dimensional (3D) cross-point (XPOINT) memories from Intel® andMicron®. The memory circuitry 504 may also comprise persistent storagedevices, which may be temporal and/or persistent storage of any type,including, but not limited to, non-volatile memory, optical, magnetic,and/or solid state mass storage, and so forth.

The individual memory devices of memory circuitry 504 may be implementedas one or more of solder down packaged integrated circuits, socketedmemory modules, and plug-in memory cards. The memory circuitry 504 maybe implemented as any number of different package types such as singledie package (SDP), dual die package (DDP) or quad die package (Q17P).These devices, in some examples, may be directly soldered onto amotherboard to provide a lower profile solution, while in other examplesthe devices are configured as one or more memory modules that in turncouple to the motherboard by a given connector. Any number of othermemory implementations may be used, such as other types of memorymodules, e.g., dual inline memory modules (DIMMs) of different varietiesincluding but not limited to microDIMMs or MiniDIMMs. Memory circuitry504. In embodiments, the memory circuitry 504 may be disposed in or on asame die or package as the processor circuitry 502 (e.g., a same SoC, asame SiP, or soldered on a same MCP as the processor circuitry 502).

To provide for persistent storage of information such as data,applications, operating systems (OS), and so forth, a storage circuitry508 may also couple to the processor circuitry 502 via the interconnect506. In an example, the storage circuitry 508 may be implemented via asolid-state disk drive (SSDD). Other devices that may be used for thestorage circuitry 508 include flash memory cards, such as SD cards,microSD cards, xD picture cards, and the like, and USB flash drives. Inlow power implementations, the storage circuitry 508 may be on-diememory or registers associated with the processor circuitry 502.However, in some examples, the storage circuitry 508 may be implementedusing a micro hard disk drive (HDD). Further, any number of newtechnologies may be used for the storage circuitry 508 in addition to,or instead of, the technologies described, such resistance changememories, phase change memories, holographic memories, or chemicalmemories, among others.

The storage circuitry 508 stores computational logic 583 (or “modules583”) in the form of software, firmware, or hardware commands toimplement the techniques described herein. The computational logic 583may be employed to store working copies and/or permanent copies ofcomputer programs, or data to create the computer programs, for theoperation of various components of platform 500 (e.g., drivers, etc.),an operating system of platform 500, one or more applications, and/orfor carrying out the embodiments discussed herein. The computationallogic 583 may be stored or loaded into memory circuitry 504 asinstructions 582, or data to create the instructions 582, for executionby the processor circuitry 502 to provide the functions describedherein. The various elements may be implemented by assemblerinstructions supported by processor circuitry 502 or high-levellanguages that may be compiled into such instructions (e.g.,instructions 570, or data to create the instructions 570). The permanentcopy of the programming instructions may be placed into persistentstorage devices of storage circuitry 508 in the factory or in the fieldthrough, for example, a distribution medium (not shown), through acommunication interface (e.g., from a distribution server (not shown)),or over-the-air (OTA).

The instructions 582 and/or modules 583 (also referred to as “programcode” or “programming instructions”) provided via the memory circuitry504 and/or the storage circuitry 508 of FIG. 5 are embodied as one ormore non-transitory computer readable storage media (NTCRSM) 560including program code, a computer program product or data to create thecomputer program, with the computer program or data, to direct theprocessor circuitry 502 of platform 500 to perform electronic operationsin the platform 500, and/or to perform a specific sequence or flow ofactions, for example, as described w.r.t the flowchart(s) and blockdiagram(s) of operations and functionality depicted by FIGS. 1-2 and6-19 . In some embodiments, the programming instructions (or data tocreate the programming instructions) to be executed may be in apre-configured form that may require configuration instructions toinstall or provision the programming instructions to an apparatus (suchas any of the devices/components/systems described herein). Wheninstalled/provisioned, configured and executed, the programminginstructions can complete or perform various programming operationsassociated with operating system functions, one or more applications,and/or aspects of the present disclosure (including various programmingoperations associated with FIGS. 1-2 and 6-19 .

The instructions 582 and/or modules 583 may include, or may be, programcode for one or more applications, components, plug-ins, firmware, etc.,which when running on the system 500, collect spatial-temporal data, andprovides this information to one or more prediction layers 205 in theLPPS 200 via a suitable access network (e.g., a NAN 131, 132, 133 and CN142 or cloud 144). An example of such an application is discussed infraw.r.t FIG. 6 . As discussed in more detail infra, the spatial-temporaldata such as operational parameters of the system 200, signalmeasurements, and/or other like data as discussed herein, which may beaccessed using suitable APIs, drivers, etc., (e.g., a modem driver foraccessing signal measurements and/or other like information from themodem 510). In some embodiments, these applications, components,plug-ins, firmware, etc., may also subscribe to the LPPS 200 to receiveLPP notifications or “hints” from the LPPS 200 (see e.g., FIGS. 13-19 ).

Additionally or alternatively, programming instructions (or data tocreate the instructions) may be disposed on multiple NTCRSM 560. Inalternate embodiments, programming instructions (or data to create theinstructions) may be disposed on computer-readable transitory storagemedia, such as, signals. The instructions embodied by a machine-readablemedium may further be transmitted or received over a communicationsnetwork using a transmission medium via a network interface deviceutilizing any one of a number of transfer protocols (e.g., HTTP). Anycombination of one or more computer usable or computer readablemedium(s) may be utilized. The computer-usable or computer-readablemedium may be, for example but not limited to, one or more electronic,magnetic, optical, electromagnetic, infrared, or semiconductor systems,apparatuses, devices, or propagation media. For instance, the NTCRSM 560may be embodied by devices described for the storage circuitry 508and/or memory circuitry 504. More specific examples (a non-exhaustivelist) of a computer-readable medium would include the following: anelectrical connection having one or more wires, a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM, Flash memory,etc.), an optical fiber, a portable compact disc read-only memory(CD-ROM), an optical storage device and/or optical disks, a transmissionmedia such as those supporting the Internet or an intranet, a magneticstorage device, or any number of other hardware devices. Note that thecomputer-usable or computer-readable medium could even be paper oranother suitable medium upon which the program (or data to create theprogram) is printed, as the program (or data to create the program) canbe electronically captured, via, for instance, optical scanning of thepaper or other medium, then compiled, interpreted, or otherwiseprocessed in a suitable manner, if necessary, and then stored in acomputer memory (with or without having been staged in or moreintermediate storage media). In the context of this document, acomputer-usable or computer-readable medium may be any medium that cancontain, store, communicate, propagate, or transport the program (ordata to create the program) for use by or in connection with theinstruction execution system, apparatus, or device. The computer-usablemedium may include a propagated data signal with the computer-usableprogram code (or data to create the program code) embodied therewith,either in baseband or as part of a carrier wave. The computer usableprogram code (or data to create the program) may be transmitted usingany appropriate medium, including but not limited to wireless, wireline,optical fiber cable, RF, etc.

The program code (or data to create the program code) described hereinmay be stored in one or more of a compressed format, an encryptedformat, a fragmented format, a packaged format, etc. Program code (ordata to create the program code) as described herein may require one ormore of installation, modification, adaptation, updating, combining,supplementing, configuring, decryption, decompression, unpacking,distribution, reassignment, etc. in order to make them directly readableand/or executable by a computing device and/or other machine. Forexample, the program code (or data to create the program code) may bestored in multiple parts, which are individually compressed, encrypted,and stored on separate computing devices, wherein the parts whendecrypted, decompressed, and combined form a set of executableinstructions that implement the program code (the data to create theprogram code such as that described herein. In another example, theProgram code (or data to create the program code) may be stored in astate in which they may be read by a computer, but require addition of alibrary (e.g., a dynamic link library), a software development kit(SDK), an application programming interface (API), etc. in order toexecute the instructions on a particular computing device or otherdevice. In another example, the program code (or data to create theprogram code) may need to be configured (e.g., settings stored, datainput, network addresses recorded, etc.) before the program code (ordata to create the program code) can be executed/used in whole or inpart. In this example, the program code (or data to create the programcode) may be unpacked, configured for proper execution, and stored in afirst location with the configuration instructions located in a secondlocation distinct from the first location. The configurationinstructions can be initiated by an action, trigger, or instruction thatis not co-located in storage or execution location with the instructionsenabling the disclosed techniques. Accordingly, the disclosed programcode (or data to create the program code) are intended to encompass suchmachine readable instructions and/or program(s) (or data to create suchmachine readable instruction and/or programs) regardless of theparticular format or state of the machine readable instructions and/orprogram(s) when stored or otherwise at rest or in transit.

Computer program code for carrying out operations of the presentdisclosure (e.g., computational logic 583, instructions 582, 570discussed previously) may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Python, Ruby, Scala, Smalltalk, Java™, C++, C#, or the like; aprocedural programming languages, such as the “C” programming language,the Go (or “Golang”) programming language, or the like; a scriptinglanguage such as JavaScript, Server-Side JavaScript (SSJS), JQuery, PHP,Pearl, Python, Ruby on Rails, Accelerated Mobile Pages Script(AMPscript), Mustache Template Language, Handlebars Template Language,Guide Template Language (GTL), PHP, Java and/or Java Server Pages (JSP),Node.js, ASP.NET, JAMscript, and/or the like; a markup language such asHypertext Markup Language (HTML), Extensible Markup Language (XML), JavaScript Object Notion (JSON), Apex®, Cascading Stylesheets (CSS),JavaServer Pages (JSP), MessagePack™, Apache® Thrift, Abstract SyntaxNotation One (ASN.1), Google® Protocol Buffers (protobuf), or the like;some other suitable programming languages including proprietaryprogramming languages and/or development tools, or any other languagestools. The computer program code for carrying out operations of thepresent disclosure may also be written in any combination of theprogramming languages discussed herein. The program code may executeentirely on the system 500, partly on the system 500, as a stand-alonesoftware package, partly on the system 500 and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the system 500 throughany type of network, including a LAN or WAN, or the connection may bemade to an external computer (e.g., through the Internet using anInternet Service Provider).

In an example, the instructions 570 on the processor circuitry 502(separately, or in combination with the instructions 582 and/orlogic/modules 583 stored in computer-readable storage media) mayconfigure execution or operation of a trusted execution environment(TEE) 590. The TEE 590 operates as a protected area accessible to theprocessor circuitry 502 to enable secure access to data and secureexecution of instructions. In some embodiments, the TEE 590 may be aphysical hardware device that is separate from other components of thesystem 500 such as a secure-embedded controller, a dedicated SoC, or atamper-resistant chipset or microcontroller with embedded processingdevices and memory devices. In other embodiments, the TEE 590 may beimplemented as secure enclaves, which are isolated regions of codeand/or data within the memory of the system 500. Only code executedwithin a secure enclave may access data within the same secure enclave,and the secure enclave may only be accessible using the secureapplication (which may be implemented by an application processor or atamper-resistant microcontroller). Various implementations of the TEE590, and an accompanying secure area in the processor circuitry 502 orthe memory circuitry 504 and/or storage circuitry 508 may be provided,for instance, through use of Intel® Software Guard Extensions (SGX) orARM® TrustZone® hardware security extensions; a Desktop and mobileArchitecture Hardware (DASH) compliant Network Interface Card (NIC),Intel® Management/Manageability Engine, Intel® Converged Security Engine(CSE) or a Converged Security Management/Manageability Engine (CSME),Trusted Execution Engine (TXE) provided by Intel® each of which mayoperate in conjunction with Intel® Active Management Technology (AMT)and/or Intel® vPro™ Technology; AMD® Platform Security coProcessor(PSP), AMD® PRO A-Series Accelerated Processing Unit (APU) with DASHmanageability, the IBM® Crypto Express3®, IBM® 4807, 4808, 4809, and/or4765 Cryptographic Coprocessors, IBM® Baseboard Management Controller(BMC) with Intelligent Platform Management Interface (IPMI), Dell™Remote Assistant Card II (DRAC II), integrated Dell™ Remote AssistantCard (iDRAC), and the like. Other aspects of security hardening,hardware roots-of-trust, and trusted or protected operations may beimplemented in the device 500 through the TEE 590 and the processorcircuitry 502.

Although the instructions 582 are shown as code blocks included in thememory circuitry 504 and the computational logic 583 is shown as codeblocks in the storage circuitry 508, it should be understood that any ofthe code blocks may be replaced with hardwired circuits, for example,built into an FPGA, ASIC, or some other suitable circuitry. For example,where processor circuitry 502 includes (e.g., FPGA based) hardwareaccelerators as well as processor cores, the hardware accelerators(e.g., the FPGA cells) may be pre-configured (e.g., with appropriate bitstreams) with the aforementioned computational logic to perform some orall of the functions discussed previously (in lieu of employment ofprogramming instructions to be executed by the processor core(s)).

The memory circuitry 504 and/or storage circuitry 508 may store programcode of an operating system (OS), which may be a general purpose OS oran OS specifically written for and tailored to the computing platform500. For example, the OS may be Unix or a Unix-like OS such as Linuxe.g., provided by Red Hat Enterprise, Windows 10™ provided by MicrosoftCorp.®, macOS provided by Apple Inc.®, or the like. In another example,the OS may be a mobile OS, such as Android® provided by Google Inc.®,iOS® provided by Apple Inc.′, Windows 10 Mobile® provided by MicrosoftCorp.®, KaiOS provided by KaiOS Technologies Inc., or the like. Inanother example, the OS may be a real-time OS (RTOS), such as ApacheMynewt provided by the Apache Software Foundation®, Windows 10 For IoT®provided by Microsoft Corp.®, Micro-Controller Operating Systems(“MicroC/OS” or “μC/OS”) provided by Micrium®, Inc., FreeRTOS, VxWorks®provided by Wind River Systems, Inc.®, PikeOS provided by Sysgo AG®,Android Things® provided by Google Inc.®, QNX® RTOS provided byBlackBerry Ltd., or any other suitable RTOS, such as those discussedherein.

The OS may include one or more drivers that operate to controlparticular devices that are embedded in the platform 500, attached tothe platform 500, or otherwise communicatively coupled with the platform500. The drivers may include individual drivers allowing othercomponents of the platform 500 to interact or control various IO devicesthat may be present within, or connected to, the platform 500. Forexample, the drivers may include a display driver to control and allowaccess to a display device, a touchscreen driver to control and allowaccess to a touchscreen interface of the platform 500, sensor drivers toobtain sensor readings of sensor circuitry 521 and control and allowaccess to sensor circuitry 521, actuator drivers to obtain actuatorpositions of the actuators 522 and/or control and allow access to theactuators 522, a camera driver to control and allow access to anembedded image capture device, audio drivers to control and allow accessto one or more audio devices. The OSs may also include one or morelibraries, drivers, APIs, firmware, middleware, software glue, etc.,which provide program code and/or software components for one or moreapplications to obtain and use the data from TEE 590.

The components may communicate over the interconnect 506. Theinterconnect 506 may include any number of technologies, includingindustry standard architecture (ISA), extended ISA (EISA), peripheralcomponent interconnect (PCI), peripheral component interconnect extended(PCIx), PCI express (PCIe), or any number of other technologies. Theinterconnect 506 may be a proprietary bus, for example, used in a SoCbased system. Other bus systems may be included, such as an I²Cinterface, an SPI interface, point-to-point interfaces, and a power bus,among others.

The interconnect 506 couples the processor circuitry 502 to thecommunication circuitry 509 for communications with other devices. Thecommunication circuitry 509 is a hardware element, or collection ofhardware elements, used to communicate over one or more networks (e.g.,cloud 501) and/or with other devices (e.g., mesh devices/fog 564). Thecommunication circuitry 509 includes baseband circuitry 510 (or “modem510”) and radiofrequency (RF) circuitry 511 and 512.

The baseband circuitry 510 includes one or more processing devices(e.g., baseband processors) to carry out various protocol and radiocontrol functions. Baseband circuitry 510 may interface with applicationcircuitry of platform 500 (e.g., a combination of processor circuitry502, memory circuitry 504, and/or storage circuitry 508) for generationand processing of baseband signals and for controlling operations of theRF circuitry 511 or 512. The baseband circuitry 510 may handle variousradio control functions that enable communication with one or more radionetworks via the RF circuitry 511 or 512. The baseband circuitry 510 mayinclude circuitry such as, but not limited to, one or more single-coreor multi-core processors (e.g., one or more baseband processors) orcontrol logic to process baseband signals received from a receive signalpath of the RF circuitry 511 and/or 512, and to generate basebandsignals to be provided to the RF circuitry 511 or 512 via a transmitsignal path. In various embodiments, the baseband circuitry 510 mayimplement a real-time OS (RTOS) to manage resources of the basebandcircuitry 510, schedule tasks, etc. Examples of the RTOS may includeOperating System Embedded (OSE)™ provided by Enea®, Nucleus RTOS™provided by Mentor Graphics®, Versatile Real-Time Executive (VRTX)provided by Mentor Graphics®, ThreadX™ provided by Express Logic®,FreeRTOS, REX OS provided by Qualcomm®, OKL4 provided by Open Kernel(OK) Labs®, or any other suitable RTOS, such as those discussed herein.

Although not shown by FIG. 5 , in one embodiment, the baseband circuitry510 includes individual processing device(s) to operate one or morewireless communication protocols (e.g., a “multi-protocol basebandprocessor” or “protocol processing circuitry”) and individual processingdevice(s) to implement PHY functions. In this embodiment, the protocolprocessing circuitry operates or implements various protocollayers/entities of one or more wireless communication protocols. In afirst example, the protocol processing circuitry may operate LTEprotocol entities and/or 5G/NR protocol entities when the communicationcircuitry 509 is a cellular radiofrequency communication system, such asmillimeter wave (mmWave) communication circuitry or some other suitablecellular communication circuitry. In the first example, the protocolprocessing circuitry 502 would operate MAC, RLC, PDCP, SDAP, RRC, andNAS functions. In a second example, the protocol processing circuitrymay operate one or more IEEE-based protocols when the communicationcircuitry 509 is WiFi communication system. In the second example, theprotocol processing circuitry would operate WiFi MAC and LLC) functions.The protocol processing circuitry may include one or more memorystructures (not shown) to store program code and data for operating theprotocol functions, as well as one or more processing cores (not shown)to execute the program code and perform various operations using thedata. The protocol processing circuitry provides control functions forthe baseband circuitry 510 and/or RF circuitry 511 and 512. The basebandcircuitry 510 may also support radio communications for more than onewireless protocol.

Continuing with the aforementioned embodiment, the baseband circuitry510 includes individual processing device(s) to implement PHY includingHARQ functions, scrambling and/or descrambling, (en)coding and/ordecoding, layer mapping and/or de-mapping, modulation symbol mapping,received symbol and/or bit metric determination, multi-antenna portpre-coding and/or decoding which may include one or more of space-time,space-frequency or spatial coding, reference signal generation and/ordetection, preamble sequence generation and/or decoding, synchronizationsequence generation and/or detection, control channel signal blinddecoding, radio frequency shifting, and other related functions. etc.The modulation/demodulation functionality may include Fast-FourierTransform (FFT), precoding, or constellation mapping/demappingfunctionality. The (en)coding/decoding functionality may includeconvolution, tail-biting convolution, turbo, Viterbi, or Low DensityParity Check (LDPC) coding. Embodiments of modulation/demodulation andencoder/decoder functionality are not limited to these examples and mayinclude other suitable functionality in other embodiments.

The communication circuitry 509 also includes RF circuitry 511 and 512to enable communication with wireless networks using modulatedelectromagnetic radiation through a non-solid medium. Each of the RFcircuitry 511 and 512 include a receive signal path, which may includecircuitry to convert analog RF signals (e.g., an existing or receivedmodulated waveform) into digital baseband signals to be provided to thebaseband circuitry 510. Each of the RF circuitry 511 and 512 alsoinclude a transmit signal path, which may include circuitry configuredto convert digital baseband signals provided by the baseband circuitry510 to be converted into analog RF signals (e.g., modulated waveform)that will be amplified and transmitted via an antenna array includingone or more antenna elements (not shown). The antenna array may be aplurality of microstrip antennas or printed antennas that are fabricatedon the surface of one or more printed circuit boards. The antenna arraymay be formed in as a patch of metal foil (e.g., a patch antenna) in avariety of shapes, and may be coupled with the RF circuitry 511 or 512using metal transmission lines or the like.

The RF circuitry 511 (also referred to as a “mesh transceiver”) is usedfor communications with other mesh or fog devices 564. The meshtransceiver 511 may use any number of frequencies and protocols, such as2.4 Gigahertz (GHz) transmissions under the IEEE 802.15.4 standard,using the Bluetooth® low energy (BLE) standard, as defined by theBluetooth® Special Interest Group, or the ZigBee® standard, amongothers. Any number of RF circuitry 511, configured for a particularwireless communication protocol, may be used for the connections to themesh devices 564. For example, a WLAN unit may be used to implementWiFi™ communications in accordance with the IEEE 802.11 standard. Inaddition, wireless wide area communications, for example, according to acellular or other wireless wide area protocol, may occur via a WWANunit.

The mesh transceiver 511 may communicate using multiple standards orradios for communications at different ranges. For example, the platform500 may communicate with close/proximate devices, e.g., within about 10meters, using a local transceiver based on BLE, or another low powerradio, to save power. More distant mesh devices 564, e.g., within about50 meters, may be reached over ZigBee or other intermediate powerradios. Both communications techniques may take place over a singleradio at different power levels, or may take place over separatetransceivers, for example, a local transceiver using BLE and a separatemesh transceiver using ZigBee.

The RF circuitry 512 (also referred to as a “wireless networktransceiver,” a “cloud transceiver,” or the like) may be included tocommunicate with devices or services in the cloud 501 via local or widearea network protocols. The wireless network transceiver 512 includesone or more radios to communicate with devices in the cloud 501. Thecloud 501 may be the same or similar to cloud 144 discussed previously.The wireless network transceiver 512 may be a LPWA transceiver thatfollows the IEEE 802.15.4, or IEEE 802.15.4g standards, among others,such as those discussed herein. The platform 500 may communicate over awide area using LoRaWAN™ (Long Range Wide Area Network) developed bySemtech and the LoRa Alliance. The techniques described herein are notlimited to these technologies, but may be used with any number of othercloud transceivers that implement long range, low bandwidthcommunications, such as Sigfox, and other technologies. Further, othercommunications techniques, such as time-slotted channel hopping,described in the IEEE 802.15.4 specification may be used.

In one example implementation, the communication circuitry 509 may be,or may include, a software defined radio (SDR) in which RF operatingparameters including, but not limited to, frequency range, modulationtype, and/or output power can be set or altered by software, and/or thetechnique by which this is achieved. Additionally or alternatively, thecommunication circuitry 509 may be, or may include, a software definedmultiradio (SDMR), which is a device or technology where multiple radiotechnologies (or RATs) coexist and share their wireless transmissionand/or reception capabilities, including but not limited to regulatedparameters, by operating them under a common software system. In eitherof these example implementations, each of the transceivers 511 and 512may be radio applications, which are software application executing in aSDR or SDMR. Radio applications are typically designed to use certain RFband(s) using agreed-to schemes for multiple access, modulation, channeland data coding, as well as control protocols for all radio layersneeded to maintain user data links between adjacent radio equipment,which run the same radio application.

Any number of other radio communications and protocols may be used inaddition to the systems mentioned for the mesh transceiver 511 andwireless network transceiver 512, as described herein. For example, theradio transceivers 511 and 512 may include an LTE or other cellulartransceiver that uses spread spectrum (SPA/SAS) communications forimplementing high-speed communications. Further, any number of otherprotocols may be used, such as WiFi® networks for medium speedcommunications and provision of network communications. The transceivers511 and 512 may include radios that are compatible with, and/or mayoperate according to any one or more of the following radiocommunication technologies and/or standards including but not limited tothose discussed herein.

Network interface circuitry/controller (NIC) 516 may be included toprovide wired communication to the cloud 501 or to other devices, suchas the mesh devices 564 using a standard network interface protocol. Thestandard network interface protocol may include Ethernet, Ethernet overGRE Tunnels, Ethernet over Multiprotocol Label Switching (MPLS),Ethernet over USB, or may be based on other types of network protocols,such as Controller Area Network (CAN), Local Interconnect Network (LIN),DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among manyothers. Network connectivity may be provided to/from the platform 500via NIC 516 using a physical connection, which may be electrical (e.g.,a “copper interconnect”) or optical. The physical connection alsoincludes suitable input connectors (e.g., ports, receptacles, sockets,etc.) and output connectors (e.g., plugs, pins, etc.). The NIC 516 mayinclude one or more dedicated processors and/or FPGAs to communicateusing one or more of the aforementioned network interface protocols. Insome implementations, the NIC 516 may include multiple controllers toprovide connectivity to other networks using the same or differentprotocols. For example, the platform 500 may include a first NIC 516providing communications to the cloud over Ethernet and a second NIC 516providing communications to other devices over another type of network.

The interconnect 506 may couple the processor circuitry 502 to anexternal interface 518 (also referred to as “TO interface circuitry” orthe like) that is used to connect external devices or subsystems. Theexternal devices include, inter alia, sensor circuitry 521, actuators522, and positioning circuitry 545. The sensor circuitry 521 may includedevices, modules, or subsystems whose purpose is to detect events orchanges in its environment and send the information (sensor data) aboutthe detected events to some other a device, module, subsystem, etc.Examples of such sensors 521 include, inter alia, inertia measurementunits (IMU) comprising accelerometers, gyroscopes, and/or magnetometers;microelectromechanical systems (MEMS) or nanoelectromechanical systems(NEMS) comprising 3-axis accelerometers, 3-axis gyroscopes, and/ormagnetometers; level sensors; flow sensors; temperature sensors (e.g.,thermistors); pressure sensors; barometric pressure sensors;gravimeters; altimeters; image capture devices (e.g., cameras); lightdetection and ranging (LiDAR) sensors; proximity sensors (e.g., infraredradiation detector and the like), depth sensors, ambient light sensors,ultrasonic transceivers; microphones; etc.

The external interface 518 connects the platform 500 to actuators 522,allow platform 500 to change its state, position, and/or orientation, ormove or control a mechanism or system. The actuators 522 compriseelectrical and/or mechanical devices for moving or controlling amechanism or system, and converts energy (e.g., electric current ormoving air and/or liquid) into some kind of motion. The actuators 522may include one or more electronic (or electrochemical) devices, such aspiezoelectric biomorphs, solid state actuators, solid state relays(SSRs), shape-memory alloy-based actuators, electroactive polymer-basedactuators, relay driver integrated circuits (ICs), and/or the like. Theactuators 522 may include one or more electromechanical devices such aspneumatic actuators, hydraulic actuators, electromechanical switchesincluding electromechanical relays (EMRs), motors (e.g., DC motors,stepper motors, servomechanisms, etc.), wheels, thrusters, propellers,claws, clamps, hooks, an audible sound generator, and/or other likeelectromechanical components. The platform 500 may be configured tooperate one or more actuators 522 based on one or more captured eventsand/or instructions or control signals received from a service providerand/or various client systems.

The positioning circuitry 545 includes circuitry to receive and decodesignals transmitted/broadcasted by a positioning network of a globalnavigation satellite system (GNSS). Examples of navigation satelliteconstellations (or GNSS) include United States' Global PositioningSystem (GPS), Russia's Global Navigation System (GLONASS), the EuropeanUnion's Galileo system, China's BeiDou Navigation Satellite System, aregional navigation system or GNSS augmentation system (e.g., Navigationwith Indian Constellation (NAVIC), Japan's Quasi-Zenith Satellite System(QZSS), France's Doppler Orbitography and Radio-positioning Integratedby Satellite (DORIS), etc.), or the like. The positioning circuitry 545comprises various hardware elements (e.g., including hardware devicessuch as switches, filters, amplifiers, antenna elements, and the like tofacilitate OTA communications) to communicate with components of apositioning network, such as navigation satellite constellation nodes.In some embodiments, the positioning circuitry 545 may include aMicro-Technology for Positioning, Navigation, and Timing (Micro-PNT) ICthat uses a master timing clock to perform position tracking/estimationwithout GNSS assistance. The positioning circuitry 545 may also be partof, or interact with, the communication circuitry 509 to communicatewith the nodes and components of the positioning network. Thepositioning circuitry 545 may also provide position data and/or timedata to the application circuitry, which may use the data to synchronizeoperations with various infrastructure (e.g., radio base stations), forturn-by-turn navigation, or the like.

In some examples, various IO devices may be present within, or connectedto, the platform 500, which are referred to as input device circuitry586 and output device circuitry 584 in FIG. 5 . The input devicecircuitry 586 and output device circuitry 584 include one or more userinterfaces designed to enable user interaction with the platform 500and/or peripheral component interfaces designed to enable peripheralcomponent interaction with the platform 500. Input device circuitry 586may include any physical or virtual means for accepting an inputincluding, inter alia, one or more physical or virtual buttons (e.g., areset button), a physical keyboard, keypad, mouse, touchpad,touchscreen, microphones, scanner, headset, and/or the like.

The output device circuitry 584 may be included to show information orotherwise convey information, such as sensor readings, actuatorposition(s), or other like information. Data and/or graphics may bedisplayed on one or more user interface components of the output devicecircuitry 584. Output device circuitry 584 may include any number and/orcombinations of audio or visual display, including, inter alia, one ormore simple visual outputs/indicators (e.g., binary status indicators(e.g., light emitting diodes (LEDs)) and multi-character visual outputs,or more complex outputs such as display devices or touchscreens (e.g.,Liquid Chrystal Displays (LCD), LED displays, quantum dot displays,projectors, etc.), with the output of characters, graphics, multimediaobjects, and the like being generated or produced from the operation ofthe platform 500. The output device circuitry 584 may also includespeakers or other audio emitting devices, printer(s), and/or the like.In some embodiments, the sensor circuitry 521 may be used as the inputdevice circuitry 586 (e.g., an image capture device, motion capturedevice, or the like) and one or more actuators 522 may be used as theoutput device circuitry 584 (e.g., an actuator to provide hapticfeedback or the like). In another example, near-field communication(NFC) circuitry comprising an NFC controller coupled with an antennaelement and a processing device may be included to read electronic tagsand/or connect with another NFC-enabled device. Peripheral componentinterfaces may include, but are not limited to, a non-volatile memoryport, a universal serial bus (USB) port, an audio jack, a power supplyinterface, etc.

A battery 524 may be coupled to the platform 500 to power the platform500, which may be used in embodiments where the platform 500 is not in afixed location. The battery 524 may be a lithium ion battery, alead-acid automotive battery, or a metal-air battery, such as a zinc-airbattery, an aluminum-air battery, a lithium-air battery, a lithiumpolymer battery, and/or the like. In embodiments where the platform 500is mounted in a fixed location, the platform 500 may have a power supplycoupled to an electrical grid. In these embodiments, the platform 500may include power tee circuitry to provide for electrical power drawnfrom a network cable to provide both power supply and data connectivityto the platform 500 using a single cable.

Power management integrated circuitry (PMIC) 526 may be included in theplatform 500 to track the state of charge (SoCh) of the battery 524, andto control charging of the platform 500. The PMIC 526 may be used tomonitor other parameters of the battery 524 to provide failurepredictions, such as the state of health (SoH) and the state of function(SoF) of the battery 524. The PMIC 526 may include voltage regulators,surge protectors, power alarm detection circuitry. The power alarmdetection circuitry may detect one or more of brown out (under-voltage)and surge (over-voltage) conditions. The PMIC 526 may communicate theinformation on the battery 524 to the processor circuitry 502 over theinterconnect 506. The PMIC 526 may also include an analog-to-digital(ADC) convertor that allows the processor circuitry 502 to directlymonitor the voltage of the battery 524 or the current flow from thebattery 524. The battery parameters may be used to determine actionsthat the platform 500 may perform, such as transmission frequency, meshnetwork operation, sensing frequency, and the like. As an example, thePMIC 526 may be a battery monitoring integrated circuit, such as anLTC5020 or an LTC2990 from Linear Technologies, an ADT7488A from ONSemiconductor of Phoenix Arizona, or an IC from the UCD90xxx family fromTexas Instruments of Dallas, TX.

A power block 528, or other power supply coupled to a grid, may becoupled with the PMIC 526 to charge the battery 524. In some examples,the power block 528 may be replaced with a wireless power receiver toobtain the power wirelessly, for example, through a loop antenna in theplatform 500. A wireless battery charging circuit, such as an LTC5020chip from Linear Technologies of Milpitas, California, among others, maybe included in the PMIC 526. The specific charging circuits chosendepend on the size of the battery 524, and thus, the current required.The charging may be performed using the Airfuel standard promulgated bythe Airfuel Alliance, the Qi wireless charging standard promulgated bythe Wireless Power Consortium, or the Rezence charging standard,promulgated by the Alliance for Wireless Power, among others.

FIG. 6 depicts example logical components and interaction points of adata collection prediction layer 600. The data collection layer 600(also referred to as a “feedback layer” or the like) corresponds to oneof the prediction layers 225-1 to 225-N of FIG. 2 , and the compute node602 corresponds to a device or system from which data is to becollected, such as a UE 111, 121, a NAN 131-133, or the like.Additionally, the LPPS application (app) 620 is an application to beoperated by the compute node 602, which obtains and/or collects data 651from various sources, performs various operations on the data 651, andprovides processed data 652 to the data collection layer 600. In someembodiments, the LPPS app 620 may also be used to subscribe to, orconsume, LPP notifications from the LPPS 200 of FIG. 2 as discussedelsewhere herein.

In the example of FIG. 6 , the LPPS app 620 collects data 651 (e.g., rawdata), which is fed to a pre-processing engine 623. The LPPS app 620 maycollect the data 651 from various components of the compute node 602using suitable APIs, ABIs, drivers, libraries, etc. In some embodiments,the data collection layer 600 may request or instruct the LPPS app 620to collect certain types of data 651 such as one or more of the types ofdata/measurements discussed herein. This process may also be referred toas “feature extraction.”

In an example, the LPPS app 620 may use a suitable driver, API, etc., tocollect signal measurement data from modem or baseband circuitry of thecompute node 602 (e.g., baseband circuitry 310 of FIG. 3 or basebandcircuitry 510 of FIG. 5 ). In another example, the LPPS app 620 may useindividual drivers, APIs, etc., to collect processor utilization andmemory utilization from processor circuitry of the compute node 602(e.g., application circuitry 305 of FIG. 3 or processor circuitry 502 ofFIG. 5 ) and memory circuitry of the compute node 602 (e.g., memorycircuitry 320 of FIG. 3 or memory circuitry 504 of FIG. 5 ),respectively. In another example, the LPPS app 620 may use respectiveAPIs, ABIs, etc., to collect application parameters/data from variousapplications running on or stored by the compute node 602. In anotherexample, the LPPS app 620 may use respective APIs, drivers, etc., tocollect sensor data (e.g., speed/velocity data, position data,orientation data, etc.) from various sensors of the compute node 602(e.g., positioning circuitry 345 of FIG. 3 , sensor circuitry 521 and/orpositioning circuitry 545 of FIG. 5 , etc.). The LPPS app 620 mayadditionally or alternatively collect data from the compute node 602according to other methods or techniques.

The pre-processing engine 623 performs various pre-processing and/ordata reduction operations on the data 651, which may include, interalia, converting the data 651 into digital data (e.g., where data 651comprises analog signals or samples of such signals), normalizing (e.g.,indexing, partitioning, augmenting, re-formatting, canonicalizing,etc.), editing, scaling, encoding, sorting, ordering, collating, and/orperforming other transformations on the data 651. The pre-processingengine 623 may also remove out-of-range values from the data 651,impossible combinations of data, removing corrupt or inaccurate data,and/or the like. These pre-processing operations may be performed inorder to ease the learning process of other prediction layers 225.

The pre-processed data may then be passed to the encryption engine 624where the pre-processed data is encrypted using a suitable cipher orencryption algorithm to produce processed data 652. The processed data652 is then sent to the data collection layer 600. Additionally, theprocessed data 652 may be packaged into appropriate messages forcommunication according to know mechanisms and protocols, such as thosediscussed herein.

In some embodiments, the LPPS app 620 may be a user or client system,such as the UEs 111, 121 of FIG. 1 , and/or the computing system 500 ofFIG. 5 . In these embodiments, the data 651 collected by the LPPS app620 and/or the data 652 provided to the data collection layer 600 mayinclude, for example, cell identifier (ID) of a cell on which the LPPSapp 620 is currently camping, a network ID of a NAN 131-133 to which theLPPS app 620 is attached, position information or geolocation of the NAN131-133; a network ID of an edge compute node 136 providing services tothe compute node 602 (if any); position information or geolocation ofthe edge compute node 136 (if any); a compute node ID, mobility stateinformation (e.g. whether the LPPS app 620 is moving or stationary, aswell as speed and direction of travel), operational parameters,measurement information (e.g., channel state and/or quality measurementsof fronthaul links 103, 105, and/or 107, BW measurements, latencymeasurements, etc.), GPS/GNSS information of the compute node 602 (e.g.,geolocation information and speed/direction of movement from positioningcircuitry 545 of FIG. 5 or the like), navigation application information(e.g., planned route or journey configuration or the like), and/or otherlike data. In these embodiments, the compute node ID may be a raw ID,obfuscated ID, or temporary ID. As examples, the compute node ID may bean International Mobile Subscriber Identity (IMSI); Mobile StationInternational Subscriber Directory Number (MSISDN); a Radio NetworkTemporary Identifier (RNTI) including a cell-RNTI (C-RNTI), temporaryC-RNTI, random access (RA)-RNTI, and/or any other RNTI(s) such as thosediscussed by 3GPP TS 38.300, 3GPP TS 36.300, and/or TS 36.401; aSubscriber or SAE Temporary Mobile Subscriber Identity (S-TMSI),Subscription Permanent ID (SUPI), Globally Unique Temporary UE Identity(GUTI), a Media Access Control (MAC) address, an IP address,manufacturer/device serial number(s) including component serialnumber(s), and/or the like.

Additionally or alternatively, the LPPS app 620 may be a NAN 131-133and/or the infrastructure equipment 300 of FIG. 3 . In theseembodiments, the data 651 collected by the LPPS app 620 and/or the data652 provided to the data collection layer 600 may include, for example,cell ID assigned to the NAN 131-133, a network to which the LPPS app 620belongs, compute node ID, operational parameters, measurementinformation (e.g., channel state and/or quality measurements offronthaul links 103 and/or 107, channel state and/or qualitymeasurements of backhaul links/interfaces, BW measurements, latencymeasurements, etc.), GPS/GNSS information (e.g., geolocation informationfrom positioning circuitry 345 of FIG. 3 or the like), and/or other likedata. In these embodiments, the data 651, 652, 653 related to the NAN131-133 may be referred to as “NAN characteristics” or the like. Inthese embodiments, the compute node ID may be a raw ID, obfuscated ID,or temporary ID. As examples, the compute node ID may be a Global eNBID, a gNB ID, a Global gNB ID, an NG-RAN ID such as any of thosediscussed in 3GPP TS 38.401, Access Point Name (APN), MAC address, an IPaddress, manufacturer/device serial number(s) including component serialnumber(s), and/or the like.

In either of the aforementioned embodiments, the cell ID may include,for example, a E-UTRAN Cell Global Identifier (ECGI), an NR Cell GlobalIdentifier (NCGI), a Service Set Identifier (SSID), or the like. Ineither of the aforementioned embodiments, the network ID may be, forexample, a domain name, a Fully Qualified Domain Name (FQDN), a PublicLand Mobile Network (PLMN) ID, Service Area Identifier (SAI), SharedNetwork Area ID (SNA-ID), Data Network Name (DNN), Network SliceSelection Assistance Information (NSSAI), Network Access ID (NAI), anenterprise network ID, or some other suitable network identityinformation.

Additionally or alternatively, the operational parameters may includeinformation regarding the device/equipment capabilities, as well ascontexts and/or constraints under which the compute node 602 (or theLPPS app 620) is operating. Examples of the operational parameters mayinclude configuration information or UE/equipment model (e.g., ahardware platform make and model, hardware component types andarrangement within the hardware platform, associated peripheral and/orattached devices/systems, processor architecture, currently runningoperating systems and/or applications and/or their requirements, etc.),subscription data (e.g., data plan and permissions for network access),security levels or permissions (e.g., possible authentication and/orauthorization required to access the LPPS app 620), etc.); computationalcapacity (e.g., a total or maximum processor speed of one or moreprocessors, a total number of VMs capable of being operated by the LPPSapp 620, a memory or storage size/capacity, an average computation timeper workload, a reuse degree of computational resources, etc.); currentor predicted computational load and/or computational resources (e.g.,processor utilization or occupied processor resources, memory or storageutilization, etc.); current or predicted unoccupied computationalresources (e.g., available or unused memory and/or processor resources,available VMs, etc.); network/communication capabilities (e.g., UEcapabilities as defined by 3GPP/ETSI standards, communicationinterfaces/circuitries of the compute node (e.g., WiFi, LTE/NR,Bluetooth/BLE, NFC, Ethernet, and/or other like chipsets), linkadaptation capabilities, configured and/or maximum transmit power,achievable data rate per channel usage, antenna configurations,supported RATs, supported functionalities of each supported RAT,subscription information of the LPPS app 620, etc.); energy budget(e.g., battery power budget); and/or other like capabilities.

The operational contexts and/or constraints may also indicate any typeof information about how a particular compute node is operating and/orthe conditions under which the LPPS app 620 is operating. Theoperational contexts and/or constraints include, for example, anoperational state of the LPPS app 620 (e.g., an on/off state of the LPPSapp 620, whether the LPPS app 620 is in an idle mode, sleep mode, activestate, etc., a currently running activity/application instance and anypaused activities/application instances, etc.); a time of day and/or adate that the operational parameters, measurements, etc. are reportedand/or collected; overload conditions experienced by the LPPS app 620;application parameters such as computational needs, input/outputcharacteristics, and volume of exchanged data with an edge compute node136, or the like; conditions of individual hardware components (e.g.,temperature, load, utilization, current or predicted available power,energy consumption measurements, etc.); environmental information of anenvironment surrounding a LPPS app 620 (e.g., temperature, ambientlight, sound/volume, altitude, humidity, moisture, information/datarelated to geographic objects (e.g., mountains) and/or human-createdobjects (e.g., buildings, highways, etc.), weather data for a givenlocation, the geolocation or other positioning information, and/or otherlike environmental measurements); operating system (OS) and/orapplication parameters and requirements; and/or other like contextualinformation.

The fronthaul and/or backhaul link conditions may include networkperformance information related to network traffic measurements (e.g.,measurements of the amount and type of traffic flowing through or acrossone or more network nodes), as well as various performance measurements.The performance measurements may include information/data related to BW,channel/link throughput and/or data rate (in uplink or downlink),latency, jitter, error rate, a number of active UEs 111, 121 and/or usersessions, packet delay, call and/or connection drops, loss rate, datavolume measurements, round trip times (RTTs) and/or round-trip delaytimes (RTDs), QoS parameters, network BW and type information, and/orthe like. The fronthaul link conditions may include the aforementionedtraffic and performance measurements, as well as information/datarelated to signal strength measurements (e.g., reference signal receivedpower (RSRP), received signal strength indicator (RSSI), etc.), signalquality measurements (e.g., reference signal received quality (RSRQ),energy per bit to noise power spectral density ratio (a/NO),signal-to-noise ratio (SNR), signal-to-interference-plus-noise ratio(SINR), etc.), channel state information (CSI), channel or networkaccess information (e.g., a number of radio resource control (RRC)connection/setup/reconfiguration attempts, a number of random accessand/or random access channel (RACH) attempts, a number of radio linkfailures (RLFs), a number of handovers (HOs)/HO attempts/HO failures,etc.), and/or other like measurement data such as those discussedelsewhere herein.

Any of the operational parameters discussed herein may be measured orotherwise determined stochastically or deterministically. The stochasticoperational parameters (or stochastic components of the operationalparameters) may be randomly determined or measured, or may have a randomprobability distribution or pattern that is analyzed statistically butmay not be predicted precisely. The deterministic operational parameters(or deterministic components of the operational parameters) may bemeasurements or information produced without randomness. In other words,the deterministic operational parameters when measured or determined arelikely to produce the same outcome given a particular situation and/orcontext.

The data 652 may be stored in a database 605 as records 653 for lateranalysis by the different layers 225. In these embodiments, the data 652may be loaded into the database 605 and/or some other data store (notshown) and stored as database objects (DBOs), key-value pairs, and/orsome other suitable data structure. In some embodiments, the data 652may be provided directly to the LPP engine 202 for direct usage. Asdiscussed in more detail infra, the data 652/653 may be used for otherprediction layers 225.

Additionally or alternatively, the pre-processing engine 623 phrases thedata 651 into a supervised learning problem, while in other embodiments,the data collection layer 600 phrases the data 652/653 into a supervisedlearning problem. In other embodiments, other prediction layers that usethe data 652/653 may phrase the data 652/653 individual for theirrespective ML models.

FIG. 7 illustrates an example cell load prediction layer 700. The cellload prediction layer 700 (also referred to as a “cell model layer” orthe like) corresponds to one of the prediction layers 225-1 to 225-N ofFIG. 2 . The cell load prediction layer 700 uses data that is specificto individual cells in order to produce performance metrics related theindividual cells for current behaviors or to produce performance metricsrelated the individual cells for future predicted behaviors. In otherwords, the cell load layer 700 determines, for each cell or NAN 131-133,predicted performance metrics (e.g., a predicted BW, and/or the like)given certain signaling/radio properties, position, operationalparameters, time of day, and/or other like information about the computenode 602 that was by the data collection layer 600.

The cell load prediction layer 700 can obtain and/or store cellcharacteristics, which is data or information about a particular celland/or NAN 131-133 that provides that cell, such as the type of RAT(s)supported in or by the NAN 131-133 providing the cell, frequency band orspectrum supported in the cell, BW(s) and/or BW parts (BWPs) of thefrequency band, a number of carrier frequencies in the frequency band,transmission range or size/shape of the cell, maximum and/or averagetransmit power of the NAN 131-133 providing the cell, geographiccoordinates of the cell (or within the cell), and/or other like cellparameters or characteristics. For example, a first cell or NAN 131-133providing an LTE cell may have different characteristics (e.g., maximumchannel BW, total cell BW, etc.) than a second cell or NAN 131-133providing a 5G/NR cell. In another example, cell or NAN 131-133 locatedin an industrial area or an urban environment may experience more noiseor interference than a cell or NAN 131-133 located in a rural area. Inanother example, cell or NAN 131-133 located in an industrial area or anurban environment may have a smaller cell size/shape and/or maximumtransmit power than a cell or NAN 131-133 located in a rural area. Thevarious characteristics of a cell or NAN 131-133 may cause the cell orNAN 131-133 to exhibit different behaviors at different time instancesunder different operational parameters or constraints.

Additionally or alternatively, the cell load prediction layer 700includes one or both of two prediction sub-layers, namelyspatial-temporal history layer 702 and a real-time load layer 704. Thespatial-temporal-history layer 702 analyses spatial-temporal-historydata 722 of the various link performance prediction options (e.g.,predicted BW, predicted latency, etc.) for different scenarios such asdifferent destinations, cell loads, signal quality, time of day, day ofthe week, date, special events, and/or the like. Thespatial-temporal-history data 722 may include data/measurements 652, 653collected from the compute node 602 and/or the data collection layer 600of FIG. 6 at previous time instances (e.g., in the past), predictedperformance metrics computed for the compute node 602 at previous timeinstances, and/or link performance predictions computed for the computenode 602 at previous time instances.

The spatial-temporal-history data 722 may be stored in a database andrepresented as timed data structure. In the example of FIG. 7 , thespatial-temporal-history data 722 includes records or database objectsfor respective time instances including a first time instance (T₁), asecond time instance (T₂), a third time instance (T₃), up to an Nth timeinstance (T_(N)) where N is a number. Each of these records or databaseobjects includes one or more data elements (DEs) such as a first DE(DE_1), a second DE (DE_2), and so forth. As an example, a value of DE_1in each record or database object may be a BW measurement taken at eachof time instances T₁-T_(N), a value of DE_2 in each record or databaseobject may be a cell load measurement taken at each of time instancesT₁-T_(N),

The real-time load layer 704 processes incoming real-time data 744 froma network operator (or CN 142, cloud 144, or the like) about the cell'sload. The real-time data 744 may indicate the cell's current or mostup-to-date load parameters, but could also include historic datapertaining to the cell's loads, which can then in turn be communicatedover to the spatial-temporal history layer 702. In one implementation,the real-time data 744 may be a suitable message including aninformation element (IE), field, or other like data structure, whichcontains a value. The value could be an enumerated value (e.g., one of“Low Load”, “Medium Load”, “High Load”, “Overload”) or one of a range ofvalues indicated an amount of occupied or utilized network resources(e.g., an integer from 1 to M, where M is a number such as a maximumnumber of PRBs or a maximum number of BWs or BWPs).

As shown by FIG. 7 , the spatial-temporal-history data 722 and thereal-time data 744 (or subsets thereof) are supplied to the cell loadmodel 710, which is a machine learning (ML) model used to predict one ormore cell characteristics, such as an expected cell performance at agiven location and time instance. In embodiments, individual cell loadmodels 710 may be generated for respective cells or NANs 131-133. Insome embodiments, the cell load model 710 is generated from one or moreML algorithms using a sample of the spatial-temporal-history data 722and the real-time data 744 during a training phase. In such embodiments,the cell load model 710 makes predictions on new or different versionsor datasets of the spatial-temporal-history data 722 and the real-timedata 744. Additionally or alternatively, the cell load model 710 may befurther refined or updated based on new/updated datasets.

Additionally or alternatively, the cell load model 710 may be aRecurrent Neural Network (RNN) with a Long Short Term Memory (LSTM),although another type of RNN may be used in other embodiments (e.g.,gated recurrent unit (GRU), echo state network (ESN), and/or the like).RNNs are a type of neural network having connections between nodes forma directed graph along a temporal sequence, which allows temporalpatterns to be identified in time-series data. RNNs can use theirinternal state (e.g., stored in memory) to process sequences of inputs,and keep track of arbitrary long-term dependencies in the inputsequences. In such embodiments, the cell load model 710 comprises one ormore cells (e.g., memory cells) to store values over arbitrary timeintervals, an input gate to control a flow of new values into thecell(s), a forget gate to control whether values in the cell(s) remainin the cell(s), and an output gate to control whether the values in thecell(s) is/are used to compute an output activation of the cell loadmodel 710. Weights assigned to the connections between the gates may bedetermined during the training phase, and these weights may determinehow the gates operate.

Additionally or alternatively, the cell load model 710 (or the datacollection layer 600 or the pre-processing engine 623 of FIG. 6 )phrases the spatial-temporal-history data 722 and the real-time data 744(or the data 651, 652, 653 of FIG. 6 ) into a supervised learningproblem, wherein the data is arranged into a set of input and outputpairs. During the training phase, the cell load model 710 is providedwith the set of input and output pairs and learns an association betweenthe pairs. Additionally, the training targets for individual cell loadmodels 710 may be different from one another since each cell load model710 may have to learn different behaviors depending on the cellcharacteristics of its corresponding cell or NAN 131-133.

The cell characteristic predictions output by the cell load model 710may include any of the aforementioned cell characteristic types (e.g.,predicted BW. Predicted cell load, etc.). The predicted cellcharacteristics are output by the cell load model 710 as a time seriesdata structure 712. In the example of FIG. 7 , the time series datastructure 712 includes a cell characteristic prediction (C) for eachfuture time instance (T_(xi)). For example, as shown by FIG. 7 , thetime series data structure 712 includes a first cell characteristicprediction (C₁) for a first future time instance (T_(x1)), a second cellcharacteristic prediction (C₂) for a second future time instance(T_(x2)) up to an Nth cell characteristic prediction (C_(N)) for asecond future time instance (Tx) where N is a number. Once generated,the time series data structure 712 is provided to the LPP layer 202 fordata fusion.

FIG. 8 shows a scenario 800 involving intra-cell characteristicpredictions. In scenario 800, the UE 821 may be the same or similar tothe UEs 121, 122 of FIG. 1 and/or the compute node 602 of FIG. 6 ; thelink 803 may be the same or similar as the link 103 of FIG. 1 ; and theNANs 832A and 832B may be the same or similar as the NANS 131-132 ofFIG. 1 .

In scenario 800, the NANs 832A and 832B are configured to providecommunication services in respective cells 838A and 838B. Additionally,the UE 821 is traveling through cell 838A and will eventually be handedover from NAN 832A to NAN 832B when the UE 821 approaches an edge of thecell 838A and/or enters cell 838B. The travel direction of the UE 821 isrepresented by the vector line 8V.

In embodiments, one of the prediction layers 225 includes an intra-celllayer, which may have a same or similar structure/implementation as thecell load prediction layer 700 of FIG. 7 , and/or may operate in a sameor similar manner as the cell load prediction layer 700 of FIG. 7 . Inembodiments, an intra-cell layer may be generated for each cell 838 orNAN 832. The cell load prediction layer 700 is used to predict BW andcell load at a given time instance, whereas the intra-cell layer 225 isused to predict signal quality and/or signal strength taking intoaccount UE 821 mobility as well as one or more other parameters. Asmentioned previously w.r.t FIGS. 6-7 , the data collection layer 600collects and stores spatio-temporal history data, which may be done on acontinuous or periodic basis, and updated or new temporalspatio-temporal history data is used to train and further refine thecell load model 710 to provide better and/or more accurate predictedperformance metrics. Similarly, the intra-cell layer 225 utilizes thespatio-temporal history data and/or real-time load data to identify ordetermine how signal properties change over time and space.

In these embodiments, the intra-cell layer 225 analyses a change insignal quality (e.g., using RSRQ, SNR, SINR, and/or the like) and/orsignal strength (e.g., using RSSI, RSRP, and/or the like) using known orpredicted movement patterns, and predicts how these signal parameterswill change for a given UE 821 at a given time instance and/or at aparticular position or geolocation within a cell 838A-B. For instance,and with reference to FIG. 8 , when the UE 821 travels through cell838A, the signal strength and/or quality of link 803 may increase and/orimprove as the UE 821 moves closer to NAN 832A, and the signal strengthand/or quality of link 803 may decrease and/or degrade as the UE 821moves away from NAN 832A and approaches cell 838B. Additionally, whenthe UE 821 is handed over to cell 838B from cell 838A, the signalstrength or quality is weak or degraded but then increases or improvesas the UE 821 moves toward the NAN 832B and/or closer to the center ofcell 838B. As the UE 821 moves closer to the edge of cell 838B, thesignal strength/quality will decrease, and finally the UE 821 will behanded over to another cell (not shown by FIG. 8 ). In a differentscenario with a small-angle directional antenna the signal will start toweakened/decrease and may increase/improve until a peak at which pointthe UE 821 is handed over to another cell. Additionally oralternatively, signal strength/quality may degrade as the UE 821approaches physical objects in a cell 838, such as man-made or naturalobjects that may obstruct or otherwise block a line-of-sight (LoS)between the UE 821 and the NAN 832.

Similar to the cell load layer 700, intra-cell layer 225 may include aspatial-temporal history sublayer and/or a real-time load sublayer,which collect and record, in suitable data structures, signalstrength/quality measurements w.r.t time/date and position/geolocationin a same or similar manner as described previously w.r.tspatial-temporal history layer 702 and real-time load layer 704 of FIG.7 . In scenario 800, these sublayers may track the signalstrength/quality increase and decreases as the UE 821 travels from cell838A to cell 838B. Additionally or alternatively, the intra-cell layermay output predicted intra-cell performance metrics in a time seriesdata structure similar to the time series data structure 712 of FIG. 7 .The predicted intra-cell performance metrics output by the intra-celllayer may include, for example, a predicted signal strength or signalquality at a given position within a cell 838 at a particular timeinstance.

Additionally or alternatively, the intra-cell layer 225 may not useexact physical locations (or geolocations) of the UE 821, and insteadmay use predicted or known movement patterns for predicting the signalstrength/quality. For example, the movement direction 8V may be a knowndirection when the NANs 832A-B are deployed along a road, a railway, orcurrently observed velocity changes (delta) versus typically observedspeeds/velocities which may be cause by, for example, traffic runningslower than normal due to an automobile accident. Additionally, thetravel speed may also be predicted based on, for example, a speed limitof the road or known train traveling speeds. These aspects are discussedin more detail w.r.t FIGS. 9 and 10 .

FIG. 9 depicts an example cell transition prediction layer 900. The celltransition layer 900 is used to predict how a UE transitions betweencells based on cell map 901, the spatio-temporal history data discussedpreviously, and real-time data discussed previously. The cell map 901 isa logical and/or mathematical representation of a group of cells or NANs131-133 in a given region or deployment area, and may include forexample, a graph data structure such as a tree or arborescence graph. Insome embodiments, the cell map 901 can be pre-configured or otherwisesupplied by a network operator that owns, operates, and/or has deployedthe cells or NANs 131-133. In some embodiments, a graph drawingalgorithm may be used to generate the graph data structure 901 based onpositioning information (e.g., geolocation coordinates) of one or moreNANs 131-133 and/or other like data.

Initially, the cell map 901 may include or represent the topology ofvarious cells (or NANs 131-133) and a subset of spatio-temporal historydata indicating UE travel directions and speeds. Additionally, the celltransition predictions 903 may also be based on other parameters besidestravel speed and direction. For example, UEs 111, 121 could be handedover to cells/NANs 131-133 experiencing better radio conditions thanother cells/NANs 131-133, or cells/NANs 131-133 having less loadcharacteristics than other cells/NANs 131-133. In some embodiments, thissubset of the spatio-temporal history data may include cell handoverhistory for the cells represented in the cell map 901. In suchembodiments, the cell map 901 may be a graph data structure thatincludes nodes representing each cell and edges between the nodesrepresenting a number of handovers between the nodes representing thosecells. Alternatively, the edges between the nodes may represent aprobability of handover between the nodes representing those cells,which may be based on the number of handovers taking place between thecells, a time that the handovers took place, and/or other likespatio-temporal history data. In either of these embodiments, the edgesmay also represent a direction of travel from one node (cell) to anothernode (cell). After this initial cell map 901 is processed by the celltransition prediction layer 900, the cell map 901 may include orrepresent cell transition predictions. In such embodiments, the cell map901 may be a graph data structure that includes nodes representing eachcell and edges between the nodes representing a direction, time, andprobability of transition.

Next, the cell map 901 is fed into a cell transition prediction model902, which uses one or more ML techniques to learn the cell transitionsand/or UE traveling behaviors using the collected spatio-temporalhistory data discussed previously w.r.t FIGS. 6-8 . In variousembodiments, the cell transition prediction model 902 is trained using asequence prediction algorithm, and is stored in or as a suitable datastructure. Sequence prediction is an ML and/or deep learning problemthat is used to predict the likelihood that an event of a sequence willoccur by only observing the previous events of that sequence. Inembodiments, after training, real time cell transitions prediction takesplace by supplying the cell prediction model 902 with relatively recentspatial-temporal history data (e.g., current cell, a previous cell, UEmobility information (e.g., travel direction and speed), currentoperational parameters of one or more UEs, and/or the like).

In some cases, UEs may travel along a fairly deterministic path, such aswhen the cells/NANs 131-133 in the cell map 901 are deployed along a setof train tracks, in or around a subway, a road or highway, or the like,at least when compared to scenarios where users are randomly travelingaround a city or the like. However, even within a relatively crowdedcity there are typically, cells/NANs 131-133 are not usually deployed ina manner that would allow UEs to attach to a random cell/NAN 131-133.Instead, there are usually a limited number of cells/NANs 131-133 near agiven cell/NAN 131-133 to which a UE can attach. In some more rarecases, a UE could be attached to a first cell/NAN 131-133 and thenattach to a second cell/NAN 131-133 that is not neighbor of the firstcell/NAN 131-133 such as, for example, when a user travels in anelevator, travels from one subway station to another subway station, orwhen a UE is turned off and turned back on at a later time in anotherlocation. Even in these rarer cases, UEs usually travel in a somewhatdeterministic manner, such that there may not be very many options for aUE to transition to a non-neighboring cell/NAN 131-133. For example,after entering a first subway station, there will likely be a relativelysmall number of potential cells/NANs 131-133 that a UE could transitionto after traveling on the subway, assuming that there are only a smallnumber of cells/NANs 131-133 at each subway station in the subwaysystem. In any of the aforementioned scenarios, there are relatively fewcells/NANs 131-133 that a UE can transition to given a current cell/NAN131-133. And, the cell transition prediction layer 900 lists thedifferent options for cell transition and the probability for thoseoptions.

In some embodiments, the sequence prediction algorithm is a CompactPrediction Tree (CPT) algorithm. A CPT comprises three data structures:a prediction tree (PT), an inverted Index (II), and a lookup table (LT).The PT is recursively defined node containing an item, a list ofchildren nodes, and a pointer to its parent node. A sequence isrepresented within a tree data structure as a full branch or a partialbranch starting from a direct child of the root node. The predictiontree is constructed by checking if a current node has a direct childmatching the first item of the sequence. If it does not, a new child isinserted to the root node with a value of the first item. Then a newlycreated child node becomes the current node, and the process is repeatedfor the next item in the training sequence. The II quickly finds inwhich sequences a given item appears. The II is a hash table containinga key for each unique item encountered during the training, where eachkey leads to a bitset that indicates IDs of the sequences where the itemappears. A bitset contains n bits, where n is the number of trainingsequences. The presence of an item in the s-th sequence is indicated bysetting the s-th bit to 1 in its bitset, and 0 otherwise. The LTcontains sequence IDs, each of which points to the last node of thesequence in the PT. The LT is updated after each sequence insertion inthe PT. Training is done using a training dataset including a set ofsequences (e.g., the initial cell map 901 discussed previously, or acell map 901 included previously predicted cell transitions), andsequences are inserted one at a time in the PT and the II. Predictionfor a given sequence S (e.g., cell transitions of the cell map 901) byperforming the intersection of the bitsets of the last x items from thesequence S, where x is a number. The resulting bitset indicates a set ofsequences Y that is/are similar to sequence S. For each similar sequenceY, each item of a consequent w.r.t the sequence S is stored in a counttable (CT). The consequent of a sequence Y w.r.t a sequence S is thesubsequence of sequence Y starting after the last item in common withsequence S until the end of sequence Y. The CT stores candidate items inassociation with a corresponding score. For example, the CT is a hashtable where the candidate items are keys and the scores the associatedvalues. The score for a candidate item represents the likelihood thatthe candidate item is the next item in the similar sequence Y. The itemwith the highest score within the CT is the predicted item.

Additionally or alternatively, the sequence prediction algorithm is arandom decision forest (also referred to as “random forest” or “randomforest regression”) algorithm. In this embodiment, the cell transitionprediction model 902 constructs a tree data structure by splitting asource dataset into subsets that constitute successor child nodes. Thesplitting is based on select a random subset of features for eachcandidate split in the decision tree. Splitting is repeated on eachderived subset in a recursive manner. Then bootstrap aggregation isperformed by building multiple decision trees (e.g., an “ensemble”) byrepeatedly resampling the training dataset with replacement. Then thecell transition prediction model 902 predicts the cell transitions byaggregating the predictions of the ensemble. The aggregation may beperformed by averaging the predictions from all the individual trees orby taking a majority vote.

Additionally or alternatively, the sequence prediction algorithm is aGraph Traversal (or graph search) algorithm such as Breadth First Search(BFS), Depth First Search (DFS) algorithms, or the like. In BFS, thecell transition prediction model 902 may start from a selected node inthe cell map 901, such as a current cell in which a UE is camping, andexplores all neighboring nodes at a present depth prior to moving on tothe nodes at the next depth level. In DFS, the cell transitionprediction model 902 may start from a selected node, such as a currentcell in which a UE is camping, and traverses each edge in the cell map901 by exploring as far as possible along each branch from the startingnode before backtracking. In either of these embodiments, the celltransition prediction model 902 may traverse the cell map 901 in orderof handover or transition probability.

During the prediction phase, the cell transition prediction model 902outputs cell transition predictions 903, which includes a listing orother indication of the next cells the UE may transition to a differenttime instances. In the example of FIG. 9 , the cell transitionpredictions 903 include a cell ID (CID) (e.g., CID₁ to CID_(N)) for eachfuture time instance (e.g., T₁ o T_(N)). In some embodiments, the celltransition prediction 903 may be fed back into the cell map 901, whichmay then be fed into the cell transition prediction layer 902 forupdated or refined cell transition predictions 903.

FIG. 10 illustrates an example cell transition graph 1000. The celltransition graph 1000 is a graph data structure mathematicallyrepresenting cells in a cell map to which a UE (e.g., the UEs 111, 121of FIG. 1 , the compute node 602 of FIG. 6 , and/or the UE 821 of FIG. 8) has or may travel. As an example, the cell transition graph 1000 maybe output by the cell transition prediction layer 902 of FIG. 9 as celltransition predictions 903 (see e.g., FIG. 9 ), and/or may be fed intothe cell transition prediction layer 902 as or with a cell map 901 forfurther refinement of the cell transition predictions 903.

A “graph” in this context refers to a data structure or data type thatcomprises a number of (or set of) nodes (also referred to as “vertices,”“points,” or “objects”), which are connected by a number of (or set of)edges, arcs, or lines. In the example of FIG. 2 , the cell transitiongraph 1000 includes 10 nodes including a previous cell 1001, a currentcell 1002, and multiple potential cells 1003 to 1009 (collectivelyreferred to as “potential cells 1003-1009” or the like). Additionally,the previous cell 1001 is connected to the current cell 1002 by edge1021; the current cell 1002 is connected to potential cell 1003 by edge1022; the potential cell 1003 is connected to potential cell 1004 byedge 1023; the potential cell 1003 is connected to potential cell 1003by edge 1024; the current cell 1002 is connected to potential cell 1005by edge 1025; the potential cell 1005 is connected to potential cell1006 by edge 1026; the current cell 1002 is connected to potential cell1007 by edge 1027; the potential cell 1007 is connected to potentialcell 1008 by edge 1028; and the potential cell 1008 is connected topotential cell 1009 by edge 1029. Additionally, in some embodiments, thecells 1001-1009 include numbers that may represent an identifier of thecell or NAN 131-133 such as a global base station ID (e.g., global gNBID, global eNB ID, global ng-eNB ID, global en-gNB ID, WiFi AP (globallyunique) MAC address, etc.), a Cell Global Identifier (CGI) (e.g., NRCGI, E-UTRAN CGI (ECGI), WiFi AP SSID, etc.), or some other identifier.

A graph may be an undirected graph having edges having no orientationand/or pairs of nodes are unordered, or a directed graph having edgeswith an orientation or pairs of vertices that are ordered. An edge hastwo or more vertices to which it is attached, called endpoints. Edgesmay also be directed or undirected; undirected edges are referred to as“lines” and directed edges are referred to as “arcs” or “arrows.” Thetwo or more vertices forming an edge may be referred to as the“endpoints” of that edge, and the edge is said to be incident to thevertices. The cell transition graph 1000 of FIG. 9 is a directed graphwith directed edges 1021-1029. The edges 1021-1029 (or “arrows1021-1029”) represent a direction of travel from one cell to anothercell, a time, and probability of a transition from one cell to another.

The probabilities of the edges 1021-1029 represent a probability orlikelihood that the UE will transition to that cell 1005 based on thecurrent cell 1002 in which the UE is camping. The probabilities may bebased on various criteria such as an expected time in a cell, currentrelative speed for cell transitions, other UE change patterns, and/orother like information. Depending on available spatio-temporal historydata, real-time data, and/or usage scenario, the cell transition layercan take the following parameters into consideration: generic clienttransition pattern, client specific motion pattern based on clientspecific identified provided by UE feedback, patterns dependent on timeof day (e.g., to office in the morning, home in the afternoon), day ofweek (e.g. home earlier on Friday), patterns mapping to supported 3GPPradio standard (e.g. a client moved between LTE cells if currently in anLTE cell), abnormal patterns (e.g. all other clients take a detouraround a roadwork on interstate), as well as relative transition time(e.g. road traffic moves slower than normal, determined by clientsearlier transition times, other clients current transition time orGeographic positioning feedback, so time in cell is longer than normal).

A cell transition prediction layer (e.g., cell transition predictionlayer 900 of FIG. 9 ) handles the respective cells logical relationshipand how the UE transitions between cells. The cell transition predictionlayer (e.g., cell transition prediction layer 900 of FIG. 9 ) uses theUE's current position (e.g., current cell 1002 in FIG. 10 ) as well asthe spatio-temporal history data to produce a prediction of thepotential cells 1003-1009 that may be visited, or a probability that theUE will transition to a given potential cell 1003-1009 at a particularfuture time instance, given the current cell 1002, a travel direction ofthe UE, the velocity of the UE, and/or other like information.

In addition to the cell transition prediction layer 900 of FIG. 9 anddiscussed w.r.t FIG. 10 , the prediction layers 225 may also include ageographic position prediction layer (not shown by FIG. 9 or 10 ). Thegeographic position prediction layer considers the physicalpositions/locations of the cells/NANs 131-133 as well as UEposition/location information. In various embodiments, the geographicposition prediction layer maps or correlates radio signal properties orpredictions determined by the cell load prediction layer 700 of FIG. 7to a physical positions/locations of UEs 111, 121, which may becollected by the data collection layer 600 of FIG. 6 . The geographicposition prediction layer can also use real-time signal measurementscollected by the data collection layer 600 of FIG. 6 , as well astraffic conditions determined by any of the prediction layers discussedherein.

The geographic position prediction layer may use various UE mobilityinformation to determine a UE's geoposition, such as sensor dataindicating a speed and direction of travel of a UE, GNSS data, mappingapplication or navigation application route data, turn-by-turnnavigation data, signal based position calculations (e.g., based onsignal strength measurements, triangulation, etc.), LTE location basedservices, and/or the like. In embodiments, the geographic positionprediction layer generates a geoposition ML model for respectivecells/NANs 131-133 using the UE mobility information (or a subset of theUE mobility information). The geoposition ML model may be generatedusing any of the ML algorithms discussed herein or some other suitableML algorithm. As mentioned previously, the geoposition ML modelcorrelates the predicted signal quality for each UE with one or moremeasurements taken at the given geolocation at the one or more timeinstances. The geoposition ML model is then used to determine predictedsignal quality for a given UE at a given geolocation at one or more timeinstances, which may be output as a suitable data structure similar tothose discussed herein.

In addition to the cell transition prediction layer 900 of FIG. 9 anddiscussed w.r.t FIG. 10 , the prediction layers 225 may also include anetwork topology prediction layer (NTPL), which predicts performance ofan overall route between a source node (e.g., a UE 111, 121, an edgecompute node 136, or server 150 sending data) and a destination node(e.g., a UE 111, 121, an edge compute node 136, or server 150 receivingdata). The NTPL considers parts of link performance other thanparameters associated with the wireless connection itself. These otherparts of link performance include, for example, intra-network andinter-network link (intra/inter-network link) performance as well asservice provider load and location. The intra/inter-network linkperformance may be based on, for example, RAN backhaul connections,datacenter connections and topology, connections and topology of NFs inthe CN 142, connections to different service provider platforms, and/orthe like. The NTPL analyzes the routes that traffic from a link 103,105, 107 will take to an intended destination, such as edge computenodes 136, CN 142, cloud 144, and/or server(s) 150 of FIG. 1 , includingthe individual hops or intermediary devices between the source anddestination nodes. In some embodiments, the NTPL generates a networktopology ML model (NTMM) or graph neural network (GNN) using a networktopology map and/or a subset of network element characteristics. TheNTMM (or GNN) may be generated using any of the ML algorithms discussedherein and/or some other suitable ML algorithm. In one example, the MLalgorithms/models used to generate the NTMM (or GNN) may be the same asthose used for the cell transition prediction layer 900 of FIG. 9 .After training, the NTMM is used to predict link quality for one or morebackhaul links and/or for a given link 103, 105, 107 based on thebackhaul links in a route between the source and destination nodes.

For the intra/inter-network link performance prediction, the NTMM (orGNN) associates the connection topology (or network topology) withcapacity and load levels of individual intra/inter-network links. TheNTMM (or GNN) may be trained on measured link performance to differentservice provider platforms (or individual servers 150) locations in anetwork, or service provider platforms (or individual servers 150)positions w.r.t a position/location of each cell or NAN 131-133. Inthese embodiments, individual services provided by the service providerplatforms (or individual servers 150) are then mapped to a closestmatching service provider platforms (or individual server 150)position/location. In embodiments, the NTMM (or GNN) uses correlationand pattern matching techniques to relate how different cells or NANs131-133 view the service provider platform (or individual server 150)positions/locations to speed up the learning and/or trainingprocess(es).

In some embodiments, the positions/locations of the service providerplatforms, individual servers 150, and/or network elements may be basedon a network topology map. The network topology map may be the same orsimilar to the cell map 901 of FIG. 9 , but describes or represents thetopology of a network operator's network where nodes represent variousnetwork elements and edges represent connections between the networkelements. In some embodiments, the NTMM can be preconfigured with anetwork operator's backend topology information in a same or similarmanner as discussed previously w.r.t FIGS. 9-10 . Additionally oralternatively, various ML techniques may be used to learn the relativepositions/locations of different endpoints/destination nodes, and howroutes between different source and destination nodes change over time.

The network element characteristics used for the intra/inter-networklink performance prediction may include information such as load levelsof individual network elements or servers 150 at different times and/orload levels for different intra/inter-network links between networkelements in a network. In some embodiments, the load onintra/inter-network links can be estimated based on capacity and load oncells. In some embodiments, load on intra/inter-network links can bemeasured by interfacing with network infrastructure in the networktopology (e.g., switches, routers, server farm servers, edge computenodes 136, network elements in the CN 142, etc.).

For the air-interface portion of the route performance prediction, theNTMM may obtain input data for each cell or NAN 131-133. This input datainclude, for example, a cell ID, cell load, noise and/or interferencemeasurements (e.g., SNR or the like), signal strength, service providerserver location, service provider server load, among other measurementsor parameters. This information may be provided by the data collectionlayer 600 of FIG. 6 and/or directly from the NANs 131-133 and/or UEs111, 121. As alluded to previously, the amount of data that can betransmitted in a PRB affects the realized and/or perceived performanceof a wireless network or a given link 103, 105, 107, and the number ofPRB slots is a function of cell load and the cell ID. Additionally, theslot bandwidth per-PRB is a function of noise measurements (and/orsignal strength measurements) and the cell ID. The noise measurementsand/or signal strength measurements are weakly dependent on each other,but this dependency is dependent on cell behavior. In embodiments, thetotal air interface performance is a function of these two functions(e.g., the number of PRB slots being a function of cell load and cellID, and the slot bandwidth per-PRB being a function of noisemeasurements (and/or signal strength measurements) and cell ID) as wellas a service provider server location and load. In such embodiments, theNTMM can include these functions, which may be trained using a suitableML algorithm, such as a regression analysis.

FIG. 11 illustrates an example data fusion engine 1100 that performscell transition and cell load data fusion for BW prediction. FIG. 11depicts an example of bandwidth prediction using cell sequence and cellload ML models performed by the data fusion engine 1100. The data fusionengine 1100 may correspond to the LPP layer 202 of FIG. 2 .

In this example, UEs 111, 121 send short-term history data to a cellsequence prediction model 1102 within the data fusion engine 1100. Theshort-term history data may include any of the measurements and/oroperational parameters discussed herein that were collected or measuredby the UEs 111, 121 during a predetermined time period, which may beexpressed as a number of days, hours, minutes, seconds, or the like. Thecell sequence prediction model 1102 also obtains one or more sequencemodels from the spatio-temporal history sequence models database 1104.The cell sequence models (and/or the spatio-temporal history sequencemodels database 1104) are stored by a suitable database system and arecontinuously updated based on the cell change history of multiple UEs111, 121. The cell sequence prediction model 1102 uses the short-termhistory data and the one or more sequence models to predict a cellchange (or transition) sequence at different time intervals (e.g.,predicted cell sequence including cells C₁, C₂, . . . C_(N) in FIG. 11where N is a number).

The predicted cell change sequence is fed to the cell BW predictionmodel 1106. Additionally, the spatio-temporal history data is fed to thecell BW prediction model 1106. The cell BW prediction model 1106 usesthe predicted cell change sequence and the spatio-temporal history datato predict a BW and other parameters at different time instances or timeintervals. As shown by FIG. 11 , the cell BW prediction model 1106outputs a data structure 1116, which includes a predicted BW for eachcell in the predicted cell sequence (e.g., including cells C₁, C₂, . . .C_(N) in FIG. 11 ) at individual time instances (e.g., predicted cellsequence including cells T₁, T₂, . . . T_(M) in FIG. 11 where M is anumber). The data structure 1116 (or portions thereof) is then sent asan LPP notification to the UEs 111, 121 so that the UEs 111, 121 canadjust their operational parameters accordingly. Additionally oralternatively, the data structure 1116 (or portions thereof) may be sentas an LPP notification to one or more NANs 131-133 that are serving UEs111, 121 and/or that are in a vicinity of the UEs 111, 121 so that theone or more NANs 131-133 can adjust their operational parametersaccordingly. Additionally or alternatively, the data structure 1116 maybe sent as an LPP notification to one or more edge compute nodes 136,the CN 142, the cloud 144, and/or server provider platforms (e.g.,server(s) 150 of FIG. 1 ) that are serving UEs 111, 121 so that thesedevices can adjust their operational parameters accordingly. In someembodiments, the data structure 1116 may be sent as an LPP notificationto the one or more NANs 131-133, which extract one or more of thepredicted BWs and transmit the extracted predicted BWs to the UEs 111,121 in some other network-specific message/signaling. Other variationsof these embodiments are also possible.

FIG. 12 illustrates an example data fusion engine 1200 that performs BWprediction. FIG. 12 depicts an example of BW prediction using an LS™based ML model, which is learned using spatio-temporal history data 1202of multiple UEs 111, 121. The data fusion engine 1200 may correspond tothe data fusion engine 1100 of FIG. 11 and/or the LPP layer 202 of FIG.2 .

In this example, each of the tables of the spatio-temporal history data1202 may correspond to an individual UE 111, 121. As shown by FIG. 12 ,each of the spatio-temporal history data 1202 tables includes a cell ID,BW measurement, a UE ID, SNR measurement, downlink (DL) latencymeasurement, signal strength measurement for respective time instances(e.g., time instances T1, T2, and T3 in FIG. 12 where T is a number).The spatio-temporal history data 1202 of the multiple UEs 111, 121 isfed into a BW prediction ML model 1201, which predicts a BW for each ofthe time instances indicated by the spatio-temporal history data 1202(e.g., time instances T1, T2, and T3 in FIG. 12 where T is a number).Each of the predicted BWs at each of the time instances is then fed intoa data fusion model 1203. In this way, the data fusion model 1203inherently learns a cell change path and BW changes over multiple timeintervals, and relationships between BW, signal strength, and SNR.During prediction, additional or alternative UE spatio-historicalhistory data (e.g., BW, latency, signal strength, SNR, cell ID, etc.) isused to predict BW and other parameters for future timeintervals/instances.

Any suitable ML model may be used for the BW prediction model 1201 andthe data fusion model 1203. In one example implementation, the BWprediction model 1201 is an LTSM neural network (NN) such as an LTSMRNN, and the data fusion model 1203 is another suitable NN such as, forexample, a deep NN, feed forward NN (FFN), deep FNN (DFF), convolutionalNN (CNN), deep CNN (DCN), deconvolutional NN (DNN), a deep belief NN, aperception NN, another RNN (e.g., including LS™, GRU, ESN, and/or thelike), spiking NN (SNN), GNN, deep stacking network (DSN), Markov chain,perception NN, generative adversarial network (GAN), transformers,stochastic NNs (e.g., Bayesian Network (BN), Bayesian belief network(BBN), a Bayesian NN (BNN), Deep BNN (DBNN), Dynamic BN (DBN),probabilistic graphical model (PGM), Boltzmann machine, restrictedBoltzmann machine (RBM), Hopfield network or Hopfield NN, convolutionaldeep belief network (CDBN), and the like), Linear Dynamical System(LDS), Switching LDS (SLDS), Optical NNs (ONNs), an NN for reinforcementlearning (RL) and/or deep RL (DRL), attention and/or self-attentionmechanisms, and/or the like. In another example implementation, the BWprediction model 1201 is an LTSM, and the data fusion model 1203 isanother LTSM. In other examples, any of the aforementioned NNs (orcombinations thereof) may be used in place or, or in addition to, any ofthe ML models employed by any of the performance prediction layersdiscussed herein.

FIGS. 13-17 illustrate example LPPS procedures 1300-1800, respectively.The procedures 1300-1800 may be performed by an LPPS consumer, an LPPSprovider, and in some cases, one or more other entities. In embodiments,the LPPS consumer may be a UE 111, 121, a NAN 131-133, an edge computenode 136, a service provider platform (e.g., one or more servers 150) ofFIG. 1 , the compute node 602 of FIG. 6 , the UE 821 and/or a NAN 832A-Bof FIG. 8 , or some other device or system discussed herein.Additionally, the LPPS provider may be the LPPS 200 and/or the LPP layer202 of FIG. 2 . From the LPPS consumer's perspective, the LPPS provideris a resource representing the LPP information or LPP notifications. Inembodiments, the connections for passing the various messages describedbelow may be sent over a secure communication channel, which may be SSLor the like. The communication channels between the LPPS consumer, LPPSprovider, and/or any other element discussed infra may be establishedand maintained using any of the mechanisms discussed herein, or thelike.

FIG. 13 illustrates an example LPPS registration procedure 1300, whichis used by LPPS consumers to register with the LPPS provider. Procedure1300 begins at operation 1303 where LPPS provisioning takes place, andthe LPPS consumer sends an indication to the LPPS provider indicatingcompletion of the LPPS provisioning. The LPPS provisioning may involveloading and installing a suitable LPPS application on the LPPS consumerdevice. At operation 1305, the LPPS provider sends an acknowledgement(ACK) message to the LPPS consumer indicating receipt of theprovisioning completion indication. The ACK message may includeinformation such as a version of the LPPS provided by the LPPS provider,a time of receipt of the provisioning indication, andsettings/configuration for receiving LPP services. At operation 1308,the LPPS consumer sends a registration request message to the LPPSprovider, and at operation 1310, the LPPS provider sends a registrationacceptance message to the LPPS consumer. In embodiments, theregistration request message may include various LPPS consumer dataand/or capabilities, and the registration accept message includes aunique key (hash_key) and a domain name of the LPPS provider. Inembodiments, the LPPS Provider may use a suitable mechanism to validatethe LPPS consumer when registering. The domain name in the registrationacceptance message may uniquely identify the LPPS provider and may beused to send LPPS requests to the LPPS provider. Additionally, thehash_key may be included in the requests for LPP notifications, which isthen used to access information about the LPPS consumer that is storedby the LPPS provider. Additionally or alternatively, the LPPS Providermay use the hash_key to validate the LPPS consumer. Moreover, theprocedures 1400-1800 of FIGS. 14-18 , respectively, may be performedonce registration is complete.

FIG. 14 illustrates a first example LPPS procedure 1400, which is basedon a request/reply model, wherein an LPPS consumer requests LPPnotifications from the LPPS provider. Procedure 1400 begins at operation1403 where the LPPS consumer sends a request message to the LPPSprovider. The request message includes a request for an LPPnotification. Additionally or alternatively, the request message mayinclude the hash_key that the LPPS consumer obtained during theregistration procedure 1300 of FIG. 13 , as well as other parametersthat may be needed to provider LPP notifications to the LPPS consumer.At operation 1405, the LPPS provider sends a reply message, whichincludes an LPP notification (LPP_data). The LPPS consumer may thenadjust its operational parameters based on the LPP_data. Operations 1403and 1405 may repeat as necessary, for example, when the LPPS consumer istriggered or otherwise desires to receive an LPP notification.

FIG. 15 illustrates a second example LPPS procedure 1500, which is basedon a subscribe/notify model, wherein the LPPS consumer subscribes toreceive LPP notifications from the LPPS provider. Procedure 1500 beginsat operation 1503 where the LPPS consumer sends a subscribe message tothe LPPS provider. The subscribe message includes a subscription requestto receive one or more LPP notifications from the LPPS provider.Additionally or alternatively, the subscribe message may include thehash_key that the LPPS consumer obtained during the registrationprocedure 1300 of FIG. 13 , as well as other parameters that may beneeded to provider LPP notifications to the LPPS consumer. In suchembodiments, the LPPS provider may add the LPPS consumer to asubscribers list or other like data structure with the informationincluded in the subscribe message. The subscribers list may includevarious LPPS consumers for which LPP notifications are to be generated.

At operation 1505A, the LPPS provider sends a notification message,which includes an LPP notification (LPP_data). The LPPS consumer maythen adjust its operational parameters based on the LPP_data. After sometime, the LPPS provider sends another notification message includingLPP_data at operation 1505B and 1505C. The LPPS provider may generateand send notification messages each time it is triggered to send suchmessages to the LPPS consumer. The triggers may be time-based triggerswherein the LPPS provider sends notification messages when a timerexpires or at periodic time intervals. The triggers may be asynchronoustriggers wherein the LPPS provider sends notification messages each timean LPP notification is generated and indicated as available fortransmission to the LPPS consumer. Other triggers, such aslocation-based triggers, application/event-based triggers, and the like,may be used in other embodiments. The LPPS provider may continue to sendnotification messages until the LPPS consumer sends an unsubscribemessage at operation 1510. In embodiments, the unsubscribe message mayinclude the hash_key that the LPPS consumer obtained during theregistration procedure 1300 of FIG. 13 and an indication or aninstruction for the LPPS provider to stop sending notification messagesto the LPPS consumer.

In some embodiments, the LPPS consumer may send link status message,which is shown as being performed at operation 1508 in FIG. 15 . Thelink status message may include measurement data or other like datarelated to link 103, 105, 107 performance, which may be used by thevarious prediction layers 225, 202 for future link performancepredictions. The LPPS consumer may send link status messages at somepredetermined or configured interval. Additionally, the LPPS consumermay send link status messages during any of the other LPPS procedures1300-1400 and 1600-1800.

FIG. 16 illustrates an example multi-endpoint LPPS procedure 600, whichis used to provide LPP notifications to an endpoint that is differentthan the LPPS consumer. The endpoint may be any of the devices orsystems discussed herein. In one example, the LPPS consumer may be a UE111, 121, and the endpoint may be a service provider platform or an edgecompute node 136. Procedure 1600 begins at operation 1603 where the LPPSconsumer sends a tell message to the endpoint via the LPPS provider. Thetell message may be sent immediately after the registration procedure1300 of FIG. 13 is complete, or at some other time after registration iscomplete. In some embodiments, the LPPS provider acts as a transparentrelay node and forwards the tell message to the endpoint. In otherembodiments, the LPPS provider extracts pertinent information from thetell message, and repackages this information (and/or adds additionalinformation) into another tell message, which is then sent to theendpoint. In either of these embodiments, the tell message may be sentusing out of band channels to provide the information to the endpoint.In either of these embodiments, the tell message includes the hash_keythat the LPPS consumer obtained during the registration process 1300,and a domain name of the LPPS provider. This information is used by endpoint to obtain LPP notifications from the LPPS provider (see e.g.,discussion of operation 1310 of FIG. 13 ). Next, the endpoint performsthe LPPS request procedure 1400 of FIG. 14 or the LPPS subscribeprocedure 1500 of FIG. 15 . In embodiments, the endpoint takes the placeof, or acts as an LPPS consumer as discussed previously w.r.t FIGS.14-15 .

FIG. 17 illustrates an example time and settings synchronization (sync)LPPS procedure 1700, which is used by the LPPS consumer and endpoint tosynchronize their local time and local LPPS settings with a referencetime and LPPS settings of the LPPS provider. Procedure 1700 begins atoperation 1703 where the LPPS consumer sends a request message to theLPPS provider. In embodiments, the request message may be sentimmediately after the registration procedure 1300 of FIG. 13 iscomplete, or at some other time after registration is complete. Thisrequest message may include a request for a reference (or global) LPPStime (e.g., “get_time” in FIG. 17 ). At operation 1705, the LPPSprovider sends a response message, which includes the reference LPPStime (e.g., “lpps_time” in FIG. 17 ). In some embodiments, the requestand response messages of operations 1703 and 1705, respectively, may besent according to the Network Time Protocol (NTP), and may includedata/information as required by the NTP. For example, the responsemessage may include a reference identifier (REFID) indicating a clocksynchronization source, and a 64 bit timestamp and/or an 128 bit datestamp. The synchronization source may be a network (e.g., CN 142 orcloud 144) or one or more external (or global) synchronization sourcessuch as a GNSS time. In other embodiments, the LPPS provider mayinstruct the LPPS consumer to use a component or embedded device as asynchronization source such as, for example, when the LPPS consumerincludes a relatively stable atomic clock, a crystal oscillator includedin positioning circuitry (e.g., positioning circuitry 345 or 545 ofFIGS. 3 and 5 , respectively), which can be used to derive an absolutetiming for synchronization. Other message and/or time formats may beused in other embodiments.

At operation 1708, the endpoint sends a request message requesting LPPSsettings from the LPPS producer. In embodiments, this request messagemay include a request for LPPS setting/configuration information (e.g.,“get_settings” in FIG. 17 ). At operation 1710, the LPPS provider sendsa response message, which includes the LPPS settings (e.g., “settings”in FIG. 17 ). In response to receipt of the response message, theendpoint may adjust or change its local settings according to thesettings/configuration information in the response message (ifnecessary). At operation 1713, the endpoint sends a reply messageindicating that the endpoint's local settings have been changed (e.g.,“set_settings” in FIG. 17 ). It should be noted that in variousembodiments, operations 1703 and 1705 may be performed by the endpointand the LPPS provider, and operation 1708-1713 may be performed by theLPPS consumer and the LPPS provider.

The various messages in each of the procedures 1300-1700 may be suitableHTTP (e.g., HTTP/1.x, HTTP/2, HTTP/3, HTTPS, SPDY, etc.) messages. Forexample, the request messages (and the reply message in FIG. 17 ) may beHTTP GET, POST, PUT, CONNECT messages or the like, with a suitablerequest line. The request/reply messages may include a body portion withthe described information as well as other information such as an LPPSconsumer instance ID (e.g., an application instance ID for LPPS app 620of FIG. 6 ). Additionally, the various response messages may be suitableHTTP response messages including a suitable status code such as “200 OK”in the header of the HTTP message, which indicates that the LPPSconsumer's request succeeded. Additionally, the requested informationmay be included in the body of the HTTP response messages. In thisembodiment, the HTTP response message may include other HTTP statuscodes, such as a bad request status code (400) (e.g., when incorrectparameters are passed in the request), a not found status code (404)(e.g., when a Universal Resource Indicator (URI) provided in the requestcannot be mapped to a valid resource URI), a forbidden status code (403)(e.g., when the operation is not allowed given the current status of theresource), and/or other like HTTP status codes. In the aforementionedexamples, the response body may include a ProblemDetails data typeindicating/including information about the particular error. Othermessage formats may be used in other embodiments, and therequest/response data may be located in the header or body portion ofsuch messages. Additionally or alternatively, a message format used forprocedures 1300-1700 includes the convention for packet definitiondiscussed by ETSI TS 102 636-4-1 V1.1.1 (2011 June). Example messageformats for this purpose are shown by FIG. 12 . The messages may beexchanged directly between vehicles and/or RSUs or through intermediaterelay stations (or relays) as illustrated by FIG. 11 .

FIG. 18 illustrates an example LPP protocol data unit (PDU) 1800. ThePDU 1800 may be any suitable data structure used by LPPS providers toconvey link performance predictions to LPPS consumers. The PDU 1800 maybe the LPP notifications discussed herein. In some embodiments, the LPPPDU 1800 may be a segment or datagram when conveyed via a transportlayer protocol (e.g., TCP, UDP, QUIC, RSVP, SCTP, VPN, MPTCP, GRE,GeoNetworking protocol, BTP, etc.), or a packet when conveyed via anetwork layer or internet layer protocol (e.g., IPv4, IPv4, etc.). Insome embodiments, the PDU 1800 could be a frame when conveyed via a linklayer, data link layer, or some other layer 2 protocol (e.g., Ethernetdata link layer; Point-to-Point (PPP); 3GPP MAC, RLC, PDCP, or SDAPlayers, etc.). In other embodiments, the PDU 1800 could be an message orother like data structure when conveyed via an application layerprotocol (e.g., Session Initiation Protocol (SIP), Session DescriptionProtocol (SDP), HTTP, SPDY, etc.). In any of the aforementionedembodiments, the PDU 1800 is identified by one or more values in aheader portion of the message (not shown by FIG. 18 ) and has a variablesize with following fields.

The N field indicates a number of LLPs that are contained within the LPPPDU 1800. Following the N field is each LPP_(x) of the number of LPPs0-N, where x is a number from 0 to N, and N is a number of linkperformance predictions indicated by the N field. Each LPP_(x) includesa timer field, a type_(x) field, a p-value_(x) field, and a prob_(x)field. The timer field includes a value that indicates a timestamp forthe x-th link performance prediction. The timestamp may be in NTP formator any other suitable timestamp format, such as those discussed herein.The type_(x) field includes a value that indicates the type of the x-thlink performance prediction. The type may be a predicted BW, a predictedlatency, a predicted transmission power, a predicted bit error rate, apredicted signal strength measurement, a predicted interferencemeasurement, a predicted noise measurement, a predicted packet lossrate, and/or a prediction of any other measurement type_(x) such asthose discussed herein. The p-value_(x) field includes a value of thepredicted measurement type indicated by the type_(x) field. The units ofthe value in the p-value_(x) field is dependent on the type ofprediction indicated by the type_(x) field. The prob_(x) field includesa value that indicates a probability that the x-th link performanceprediction indicated by the p-value_(x) field will actually occur at thetimestamp indicated by the timer field. In some embodiments, the valuein the prob_(x) field is an estimated standard deviation of the linkperformance prediction. The values included in any of the aforementionedfields may be numerals or characters, but the type of informationincluded in each field may be dependent on the type of protocol used toconvey the LPP PDU 1800.

FIG. 19 depicts an example process 1900 for practicing the variousembodiments discussed herein. In particular, process 1900 may beperformed by an LPPS provider, such as the LPPS 200 of FIG. 2 , toprovide LPPs to one or more LPPS consumers, such as the UEs 111, 121,NANs 131-133, edge system/network 135, edge compute nodes 136, CN 142,cloud 144, and/or server(s) 150 of FIG. 1 , and/or any other device orsystem discussed herein. While particular examples and orders ofoperations are illustrated FIG. 19 , the depicted orders of operationsshould not be construed to limit the scope of the embodiments in anyway. Rather, the depicted operations may be re-ordered, broken intoadditional operations, combined, and/or omitted altogether whileremaining within the spirit and scope of the present disclosure.

Process 1900 begins at operation 1905 where the LPPS provider obtainsobtain predicted performance metrics from individual prediction layersof a set of prediction layers. Individual prediction layers userespective ML algorithms to generate corresponding ML models, which areused to generate respective predicted performance metrics. Additionallyor alternatively, at least one prediction layer uses an ML algorithmand/or ML model that is different than ML algorithms and/or ML modelsused by other prediction layers. The set of prediction layers may be theprediction layers 225-1 to 225-N of FIG. 2 and/or any of the predictionlayers discussed previously w.r.t FIGS. 6-10 .

At open loop operation 1910, the LPPS provider processes each link(e.g., links 103, 105, 107 of FIG. 1 ), in turn, for example, byperforming operations 1915 to 1925 for each link. Additionally oralternatively, at open loop operation 1910, the LPPS provider performsoperations 1915 to 1925 for each of one or more LPPS consumers (e.g.,each of a plurality of UEs 111, 121 being served by one or more NANs131-133 of FIG. 1 ). At operation 915, the LPPS provider determines anLPP for the link based on the obtained predicted performance metricsand/or various combinations thereof. In some embodiments, the LPPSprovider employs a suitable data fusion technique to determine the LPP,and/or predicts a value of the LPP based on a suitable probabilitydistribution. At operation 1920, the LPPS provider generates an LPPnotification (e.g., LPP PDU 1800 of FIG. 18 ) indicating the determinedLPP. At operation 1925, the LPPS provider sends the LPP notification tothe LPPS consumer or one or more endpoints (see e.g., FIGS. 16-17 ). Atclose loop operation 1930, the LPPS provider proceeds back to operation1910 process the next link (or LPPS consumer), if any. When there are nomore links (or LPPS consumers) to process, process 1900 may end orrepeat as necessary.

In various embodiments, the LPPS provider may be an apparatus comprisingprocessor circuitry (e.g., application circuitry 305 of FIG. 3 ) coupledwith network interface circuitry (e.g., network controller circuitry 335of FIG. 3 ). The network interface circuitry communicatively couples theapparatus with one or more NANs 131-133, each of which provide networkconnectivity to one or UEs 111, 121 via respective links 103, 107between the individual NANs 131-133 and the one or more UEs 111, 121.

According to a first embodiment, the processor circuitry is arranged tooperate an LPP engine to perform 1910 to 1930, which includescontrolling the network interface circuitry to send the LPP notificationat operation 1925. In the first embodiment, the plurality of predictionlayers are operated by remote computing devices, and the networkinterface circuitry may obtain the predicted performance metrics fromthese remote computing devices at operation 1905. As an example of thefirst embodiment, individual prediction layers are operated byrespective edge computing servers (e.g., edge compute nodes 136 of FIG.1 ), application servers (e.g., one or more servers 150 of FIG. 1 ), orRANs (e.g., including RAN nodes 131-132 of FIG. 1 ), and the networkinterface circuitry is arranged to receive the predicted performancemetrics from the respective edge computing servers, application servers,and/or RANs. In the first embodiment, the apparatus may be disposed in aserver computing system that is part of a cloud computing service (e.g.,cloud 144 of FIG. 1 ), a cellular core network (e.g., CN 142 of FIG. 1), a service provider platform (e.g., one or more servers 150 of FIG. 1), an edge network (e.g., an edge compute node 136 within edge network135 of FIG. 1 ), and/or the like.

According to a second embodiment, the processor circuitry is arranged tooperate an LPP engine to perform 1905 to 1930, which includescontrolling the network interface circuitry to send the LPP notificationat operation 1925. In the second embodiment, the plurality of predictionlayers and the LPP engine are operated by the apparatus and/or a systemin which the apparatus is deployed, and the processor circuitry obtainsthe predicted performance metrics from the individual prediction layersat operation 1905. The system in which the apparatus is deployed may beone or more cluster nodes in a cloud computing service (e.g., cloud 144of FIG. 1 ). As an example of the second embodiment, the plurality ofprediction layers and the LPP engine are operated by respective VMsand/or containers (e.g., Docker® containers, Kubernetes™, etc.) on topof virtualization infrastructure provided by the apparatus or a systemin which the apparatus is disposed. In the second embodiment, theprocessor circuitry obtains the predicted performance metrics from theindividual prediction layers at operation 1905 using a suitable API(s),proxy application(s), trusted application(s), virtual/VM switch(es), VMnetwork address translator(s) (NAT), etc. In the second embodiment, theapparatus may be disposed in a server computing system that is part of acloud computing service (e.g., cloud 144 of FIG. 1 ), a cellular corenetwork (e.g., CN 142 of FIG. 1 ), or a service provider platform (e.g.,one or more servers 150 of FIG. 1 ), and the processor circuitry orvirtualization infrastructure is arranged to operate the individualprediction layers.

Implementation of the preceding techniques may be accomplished throughany number of specifications, configurations, or example deployments ofhardware and software. It should be understood that the functional unitsor capabilities described in this specification may have been referredto or labeled as components or modules, in order to more particularlyemphasize their implementation independence. Such components may beembodied by any number of software or hardware forms. For example, acomponent or module may be implemented as a hardware circuit comprisingcustom very-large-scale integration (VLSI) circuits or gate arrays,off-the-shelf semiconductors such as logic chips, transistors, or otherdiscrete components. A component or module may also be implemented inprogrammable hardware devices such as field programmable gate arrays,programmable array logic, programmable logic devices, or the like.Components or modules may also be implemented in software for executionby various types of processors. An identified component or module ofexecutable code may, for instance, comprise one or more physical orlogical blocks of computer instructions, which may, for instance, beorganized as an object, procedure, or function. Nevertheless, theexecutables of an identified component or module need not be physicallylocated together, but may comprise disparate instructions stored indifferent locations which, when joined logically together, comprise thecomponent or module and achieve the stated purpose for the component ormodule. A component or module of executable code may be a singleinstruction, or many instructions, and may even be distributed overseveral different code segments, among different programs, and acrossseveral memory devices or processing systems. In particular, someaspects of the described process (such as code rewriting and codeanalysis) may take place on a different processing system (e.g., in acomputer in a data center), than that in which the code is deployed(e.g., in a computer embedded in a sensor or robot). Similarly,operational data may be identified and illustrated herein withincomponents or modules, and may be embodied in any suitable form andorganized within any suitable type of data structure. The operationaldata may be collected as a single data set, or may be distributed overdifferent locations including over different storage devices, and mayexist, at least partially, merely as electronic signals on a system ornetwork. The components or modules may be passive or active, includingagents operable to perform desired functions.

Additional examples of the presently described method, configuration,system, and device embodiments include the non-limiting examplesdescribed in '919 and '352. Each of the non-limiting examples may standon its own, or may be combined in any permutation or combination withany one or more of the other examples provided below or throughout thepresent disclosure.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.Additionally, the terms and definitions described in '919 and '352 mayalso be applicable to the example embodiments discussed herein. As usedherein, the singular forms “a,” “an” and “the” are intended to includeplural forms as well, unless the context clearly indicates otherwise. Itwill be further understood that the terms “comprises” and/or“comprising,” when used in this specification, specific the presence ofstated features, integers, steps, operations, elements, and/orcomponents, but do not preclude the presence or addition of one or moreother features, integers, steps, operation, elements, components, and/orgroups thereof. The phrase “A and/or B” means (A), (B), or (A and B).For the purposes of the present disclosure, the phrase “A, B, and/or C”means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).The phrase “X(s)” means one or more X or a set of X. The description mayuse the phrases “in an embodiment,” “In some embodiments,” “in oneimplementation,” “In some implementations,” “in some examples”, and thelike, each of which may refer to one or more of the same or differentembodiments, implementations, and/or examples. The terms “comprising,”“including,” “having,” and the like, as used w.r.t the presentdisclosure, are synonymous.

The foregoing description provides illustration and description ofvarious example embodiments, but is not intended to be exhaustive or tolimit the scope of embodiments to the precise forms disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of various embodiments. Wherespecific details are set forth in order to describe example embodimentsof the disclosure, it should be apparent to one skilled in the art thatthe disclosure can be practiced without, or with variation of, thesespecific details. It should be understood, however, that there is nointent to limit the concepts of the present disclosure to the particularforms disclosed, but on the contrary, the intention is to cover allmodifications, equivalents, and alternatives consistent with the presentdisclosure and the appended claims.

1. An apparatus employed as a link performance prediction (LPP) serviceprovider, the apparatus comprising: network interface circuitry arrangedto communicatively couple the apparatus with one or more network accessnodes (NANs), wherein individual NANs of the one or more NANs arearranged to provide network connectivity to one or more user equipment(UEs) via respective links between the individual NANs and the one ormore UEs; and processor circuitry connected to the network interfacecircuitry, wherein the processor circuitry is to: obtain an LPP servicerequest from an LPP service consumer via the network interfacecircuitry, wherein the LPP service request is a request for LPP servicesfrom the LPP service provider, determine an LPP for a link based on aset of predicted performance metrics obtained from a set of performanceprediction layers (PPLs), and send an LPP notification to the LPPservice consumer via the network interface circuitry, wherein the LPPnotification includes the determined LPP.
 2. The apparatus of claim 1,wherein the processor circuitry is to determine the LLP based on acombination of the one or more predicted performance metrics.
 3. Theapparatus of claim 1, wherein the LPP service request is a requestmessage, the LPP notification is a reply message, and the processorcircuitry is to: determine the LPP based at least in part on informationcontained in the request message; and generate the LPP notification inresponse to receipt of the request message.
 4. The apparatus of claim 1,wherein the LPP service request is a subscribe message, the LPPnotification is a notify message, and the processor circuitry is to: addan identifier associated with the LPP service consumer and informationcontained in the subscribe message to a subscriber list; detect atrigger to determine the LPP for the link; and in response to detectingthe trigger, generate the LPP notification and send the notify messageto the LPP service consumer.
 5. The apparatus of claim 1, wherein theLPP notification is to cause the LPP service consumer to perform one ormore operational decisions for link resource utilization based on theLPP notification.
 6. The apparatus of claim 1, wherein the LPPnotification includes a time field to indicate a timestamp of thecorresponding LPP, a type field to indicate an LPP type of thecorresponding LPP, a value field to indicate a value of the LPP, and aprobability field to indicate a likelihood that the corresponding LPPcomes true or an estimated standard deviation of the corresponding LPP,wherein the LPP type is one of bandwidth, latency, jitter, round triptime (RTT), number of interrupts, out-of-order delivery of data packets,transmission power, bit error rate, bit error ratio (BER), packet lossrate, a packet reception rate (PRR), a signal-to-noise ratio (SNR), asignal-to-noise and interference ratio (SINR), asignal-plus-noise-plus-distortion to noise-plus-distortion (SINAD)ratio, a peak-to-average power ratio (PAPR), a Block Error Rate (BLER),a Reference Signal Received Power (RSRP), a Reference Signal ReceivedQuality (RSRQ), a Received Signal Strength Indicator (RSSI), a channelinterference measurement, a thermal noise power measurement, a receivedinterference power measurement, network or cell load, a recommendedtransmission power.
 7. The apparatus of claim 1, wherein, to determinethe LPP, the processor circuitry is to: combine the one or morepredicted performance metrics from individual PPLs of the set of PPLswith one or more other predicted performance metrics from at least oneother prediction layer of the set of PPLs.
 8. The apparatus of claim 1,wherein a subset of PPLs of the set of PPLs is arranged to use acorresponding machine learning (ML) algorithm to generate an ML modelfor corresponding NANs of the one or more NANs, and each PPL in thesubset of PPLs is arranged to use the corresponding ML model for thecorresponding NANs to generate respective predicted performance metrics.9. The apparatus of claim 8, wherein at least one PPL of the subset ofPPLs is arranged to use an ML algorithm that is different than MLalgorithms used by other PPLs of the subset of PPLs.
 10. The apparatusof claim 9, wherein the processor circuitry is arranged to operateindividual prediction layers in respective virtual machines (VMs) orvirtualization containers.
 11. The apparatus of claim 10, wherein theapparatus is a System-On-Chip (SoC) or a Multi-Chip Package (MCP)disposed in a server computing system, the server computing system is tooperate as an application server, an edge compute node, a web server,and one or more cloud compute nodes of a cloud computing service. 12.The apparatus of claim 1, wherein the individual prediction layers areto be operated by respective edge compute nodes, and the networkinterface circuitry is arranged to receive the predicted performancemetrics from the respective edge compute nodes.